YYTypeScript#3「VueをTSで書いて良かったこと、大変だったことを教えて！」「React Hooksの最適な粒度って？」「クライアントサイドDDD」「皆さん、decorator自作してますか？」「Node.jsゼロインストールのメリットって何？」

これは2019年10月4日に開催したTypeScriptイベント[YYTypeScript#3]のイベントレポートです。

[YYTypeScript#3]: https://yyts.connpass.com/event/145809/
[YYTypeScript]: https://yyts.connpass.com/

[YYTypeScript]は一言で「TypeScripterの部室」です。発表者の話を聞く「一方向的な勉強会」とは真逆で、TypeScriptについて、雑に・ゆるく・ワイワイ話しながらTypeScripter同士の交流を深める「双方向的な座談会」の形式になります。集まった人たちで「今日話たいこと」「聞きたいこと」をいくつか挙げていき、それをテーマに雑談していきます。

__今回の配信動画__

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">今日のYYTypeScriptの収録をアップしました！<a href="https://t.co/qDy7W8y8ux">https://t.co/qDy7W8y8ux</a></p>&mdash; suin❄️TypeScriptが好き (@suin) <a href="https://twitter.com/suin/status/1180092521893904384?ref_src=twsrc%5Etfw">October 4, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

__過去回の配信動画__ → [YouTubeプレイリスト「YYTypeScript」](https://www.youtube.com/playlist?list=PLpOeTEye3Bg4N8f7GSaeqM0p2dcdiZHv_)
__前回__ →  [YYTypeScript#2「トランスパイル後のJSのパフォーマンス」「npmモジュールの信頼性、どう担保してる？」「コンパイルが遅い」「みんなのtslintの設定とかTipsを教えて」「オブジェクトの構築と実行について」 - Qiita](https://qiita.com/suin/items/b98d4a33529c3debd822)

## 雑談

### Vue.jsをTypeScriptで書いて良かったこと・大変だったことを聞きたい (にしかわ)

* メリット
    * 型の情報が手に入る
        * propsでバリデーションは定義できるが、いちいち定義まで戻らなくてもstringなのか、numberなのかIDE/editorで分かる。
    * JSからTSに移行することのメリットと一致すると思う。
* 大変だったこと
    * Vue.jsとTSの相性があんまりよくない。
    * HTMLテンプレート内で型チェックもIDEの型補完が効かない。
        * VS Codeではプラグインありませんでしたっけ？
            * まだ対応しているプラグインはないと思います。
        * WebStormも無理でした。
        * Reactは全部JSなので、このへんは羨ましい。

・・・

* 良かったこと
    * ドキュメントの代わりになる
* 大変だったこと
    * Nuxtまわりで苦労した
    * Vuexが面倒だったので、observableでやった
        * Vuexとは？
            * Fluxアーキテクチャ、unidirectional data flowを実現するフレームワーク。
            * ビュークスと読む。
    * TSを使うならフレームワークと疎結合にすることだと思って、設計を考えた。
    * React

・・・

* 良かったこと
    * [ktsn/vuex-smart-module: Type safe Vuex module with powerful module features](https://github.com/ktsn/vuex-smart-module)を使うと、Vuexで冗長な型情報を書かなくてよくなる

・・・

* 型のメリットを得られることも、得られないことも。
* 頑張らないTypeScriptで始めるのもあり
    * [TypeScript再入門「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に（gfx執筆） - エンジニアHub｜若手Webエンジニアのキャリアを考える！](https://employment.en-japan.com/engineerhub/entry/2019/04/16/103000)
    * コンパイラ設定はキツ過ぎず、緩すぎないの加減が難しいっす。
* 昔のTSはもっと厳しくて挫折した記憶あり
* コンパイラの設定がある程度キツいと、困ったときに、どうすればいいのかわからないとかあるのかも
    * 慣れてると、どこにエラーが出てるかとか見ると、どこを修正すればいいかわかるけど、エラーが大量に出るようなケースだと、初学者は悩むかも
    * エラーが連鎖するようなやつとか）

### React Custom hooksのどの粒度で切ればいいか、設計について聞きたい (ドラレプ)

* hooksとは？
    * もともと、Reactはclassでコンポーネントを書く
    * その後、function componentという関数で書けるコンポーネントも出てきた。
        * ステートレスの流れで。
    * function component（React.FC）に状態を入れられるようになった。
        * 正確にいうと、function componentじゃないと動かない（クラス型だとだめ）
    * 状態を入れられる機能がhooks。

* どういう課題があるのか？
    * Hooksは（カスタムフックとかも含めて）めちゃくちゃ自由度が高い
        * これは、設計をクリーンにするっていう方向性に持って行ける利点がある
    * ベタにコンポーネントを書くと、コンポーネントがアホみたいに肥大化する（1関数に全部ぶち込む感じ）
    * function componentに直接コードを書くのはアンチパターン
        * useEffectとかのコールバック経由で書く必要がある（考え方を少し変える必要あり）

* erukiti式
    * まずはベタにコンポーネントを書く
    * で、カスタムフックに外だしできるものを外だしする
    * 切り分けは、責務とか意味で切り分けるといいかも
    * あ、あとカスタムフックは、unit test できるので、テストしやすい作り方を考慮するといいかも
        * https://www.npmjs.com/package/@testing-library/react-hooks

* [Essential React Hooks Design Patterns - ITNEXT](https://itnext.io/essential-react-hooks-design-patterns-a04309cc0404)
* 実際、React Hooksは、デザインパターンなり、ある程度フックスの書き方指針は必要だなーと常々思ってます

### クライアントサイドDDDってどんなの？ (すいん)

* やろうとしたが断念した。
    * 純粋に自分の中で正解が見つからないまま時間がたったので。
    * 得られたこと
        * インフラ層のDIPすると、GraphQLから別のにできるのはフロントエンドでも良さそう
* TS/JSでDIってどうやってる？
    * DIコンテナ何使ってる？
    * [InversifyJS a powerful IoC container for JavaScript apps powered by TypeScript](http://inversify.io/)ってのもあるよ。
    * DIは考えるんじゃなくて感じるんだ！！！！
    * 先週張った　https://github.com/noxtjs/gateway　はそれやるライブラリです
* クライアントサイドでドメインをと考えると、画面固有のDDDになりそう
    * Humble Object Pattern 重要(プレゼンテーションとビューを分ける。テスタブルなのをpresentationに)
    * クライアントサイドの関心は画面なので。
    * DDD/The Clean Arcthiecture は、ユースケースから考えると良いです
* TypeScript 必須（と思う)
    * interface or type を切ったり、DIPを工夫したりが必須
    * 知識を分離するのがミソですね
* 画面側はClean Architectureで感がたほうがすっきりしそうな気がする

### decorator自作していますか？使っているとしたらどんな機能を作ったのか聞きたい。(ましろ)

* decoratorって？
    * [デコレータ | TypeScript 日本語ハンドブック | js STUDIO](http://js.studio-kingdom.com/typescript/handbook/decorators)
    * インターフェイスを変えずに機能を追加できる
    * デコレータパターンを言語仕様に取り込んだものよね

```typescript=
@foo
class Bar {
    
}
```

* decoratorはexperimentalな機能ではあるが、結構使われている
* アスペクト指向的なやつを作ってみたいかな。
* Railsのdelegate的なdecoratorを書いたことある
* [TypeScript: デコレーターで実行時もイミュータブルなクラスを実現する - Qiita](https://qiita.com/suin/items/56dfe7579509d7067e10)
* 使い方が自分でなかなか思いつかないんですよね。
    * デコレータパターンから考えたほうがいいかも。
        * [Decorator](https://refactoring.guru/design-patterns/decorator)
* [Decorator](https://refactoring.guru/design-patterns/decorator)

### 「Node.jsでゼロインストール」のユースケースって？ (すいん)

[Node.jsでゼロインストールを実現する - Qiita](https://qiita.com/erukiti/items/bb4b731bd73ec4bbb1b1)

* 元ネタ
    * https://yosuke-furukawa.hatenablog.com/entry/2019/06/10/113111
    * npm tink や yarn v2 (berry)のような、次世代パッケージマネージャに入る予定の機能
* 今回やったやつは実験目的ではあるんだけど、基本的にはゼロインストールの方向性は今後のびると思ってたり
    * デプロイするときは、普通に install すればいいと思う
* 想定ユースケース
    * 実験的に動かしたい時に、いちいちnode_modulesが肥え太るとめんどい！！！！！（サイズとか）
        * つまり、雑に動かしたいときに使う！ & 開発者に優しい
        * プロダクションだともう、普通に install しちゃえばいいと思う
    * ブログにも書いてるけど、git とかから引っ張ってきて、インストールせずに動く
    * 起動に何分も待ちたくないとき
        * ちなみに軽いモノを動かす程度なら時間は掛からない（fetch すぐ）
* どう次世代か？
    * 結構ハックが必要なので、時間がかかりそうなので次世代かなー感
        * native module とか presintall scripts とかの対処も面倒（課題解決待ちなところあるとは思う）
    * あと、deno がパッケージシステムを完全否定してるので、時代の流れ？？
    * パッケージって、Node.js固有なのでブラウザとの互換性が気になる人たちもいる感じ（denoもブラウザとの互換性を大切にしてる）
* あと、ゼロなんとかが流行り
    * ゼロコンフィグ（ParcelとかWebpack v4とかNext/Nuxtとか）
* 遅延インストールみたいな感じ？なんでしょうか
    * かなー？キャッシュがあればキャッシュから引っ張ってくるし
    * 前回 npm-package のセキュリティどうなの？みたいのあったけど影響無いですかね？
        * いちおうハッシュ値とってたりするので、そこらへんで確認ですかね

### 'localhost'と127.0.0.1の違いって何？ (かきうち)

* localhost vs 127.0.0.1
    * localhostの参照先は`/etc/hosts`に記述されている
    * localhostの名前解決→IPアドレス分かる→そのIPアドレスに繋ぐ。
* MySQLの場合の違い
    * localhostだとunix domain socketがあればそれでつなぎにいく。

### 開始前の雑談

* philomagiさんがゆめみさんのイベントでしたLTの話
    * v-if便利だけど、else-ifが重なってきたり、条件が複雑になってくると大変。
    * [複雑なv-ifに負けないために - Speaker Deck](https://speakerdeck.com/tooppoo/fu-za-nav-ifnifu-kenaitameni)
    * ↑の発表内で公開したサンプルアプリです
        * [sample-for--vue-with-complex-conditions/App.vue at master · tooppoo/sample-for--vue-with-complex-conditions](https://github.com/tooppoo/sample-for--vue-with-complex-conditions/blob/master/src/App.vue)

## おすすめほん

* [【冊子・PDF】TypeScript CompilerAPI - 創出の落書帳 - - takepepe - BOOTH](https://takepepe.booth.pm/items/1575217)
* [【PDF】TypeScript CompilerAPI - 創出の落書帳 - - takepepe - BOOTH](https://takepepe.booth.pm/items/1575202)

・・・

* そういや、これがとても良かったです（TS compiler API でメタプロするやつ）
* babel で無理矢理TSメタプロするよりは良さそう・・・
* そういえば、この本にも、Vuexの型付けの話、載ってましたね！

・・・

* TypeScript compilerAPI 使うと、型情報取ったりとかで遊べます！
* Vuexとかで悩んでる人の救世主になるかも！
* 定義生成で、いうと gRPCとかGraphQLとかと合わせて何か遊べるかも

## 参加してよかったこと(参加者の感想)

* このyy形式が凄く面白い。
* 聞いたことない単語を聞けたこと
* localhost 127.0.0.1 の違いがふわっとわかった
* ずっとVue.jsを書いてたので、Reactの情報が聞けて良かったです。
* 色々助けてくれそうなライブラリ/ツールの存在を知ることが出来た
* 改めて知らなかったことがたくさんあるなーと感じて、今後色々と触ってみたいものが増えました！

## YYTypeScriptは毎週やってます

YYTypeScriptについてワイワイ話したい方は、[YYTypeScriptのイベント情報](https://yyts.connpass.com/)をチェックしてみて下さい。

以上、YYTypeScriptのレポートでした。次回もワイワイやっていきたいと思います！ では、また来週！