これは2019年11月1日に開催したTypeScriptイベントYYTypeScript#7のイベントレポートです。
YYTypeScriptは一言で「TypeScripterの部室」です。発表者の話を聞く「一方向的な勉強会」とは真逆で、TypeScriptについて、雑に・ゆるく・ワイワイ話しながらTypeScripter同士の交流を深める「双方向的な座談会」の形式になります。集まった人たちで「今日話たいこと」「聞きたいこと」をいくつか挙げていき、それをテーマに雑談していきます。
今回の配信動画
YYTypeScript#7の収録をアップしました😌https://t.co/JBRpBLyGSy
— suin❄️Terraformエンジニア募集中 (固定ツイ参照) (@suin) November 1, 2019
過去回の配信動画 → YouTubeプレイリスト「YYTypeScript」
前回 → YYTypeScript#6「JSのプロジェクトにTypeScriptを入れるときの知見」「aspida.jsはAPIクライアントを自動生成するツール」「WebStormとPrettierの相性悪い？」「TypeScript 3.7では何が変わる」「関数型のテストの書き方」「TypeScriptのエディタはVS CodeかIntelliJか」 - Qiita
雑談
他の言語からTSに来てみての感想は？
TS使う前の言語は何使ってた？ TSを使ってみてどういう感想を持ったか？
・・・
- (かきうち) 一瞬JS → Javaちょっと → PHP → TS
- （くまもん） Ruby → PHP7 → PHP5.3 ~ PHP5.6 → Go → JS → TS
- （すいん） JS → VBS → PHP4~5 → Go → Scala → PHP7 → TS
- （れおりん） Basic → C → Perl → PHP5 → JS → Java → Scala → PHP7 → TS
- TS型指定が柔軟にできていい
- 型推論すごい
- (じま) JS → アセンブラ → JS → Java → C# → めっちゃJS → Java → TS → Java → PHP → TS
- TSでたてでいろいろサポートしてなくて、ひたすら苦しんだ思い出がある
- 最近はまた書いてみて、そういうのが少なくなって快適になった
- (じゅり) JS → Java → PHP5 → Java → JS → TS
- Java型つけられるので、JavaからPHPに行ったときにいやな気持になった
- なんでもはいるのが
- JSもなんでも入るけど、DOM操作が楽しかったので良かった。
- TSでてきてええやん。型指定できるし。IDE補完してくれるし。
- Java型つけられるので、JavaからPHPに行ったときにいやな気持になった
- (ふじた) JS → PHP → これからTS
- (やまなか) C → C++ → Java → めっちゃC# → Swift → Kotlin → TS → JS → TS → Rust
- キーワードがC#と似ているのでとっつきやすさが良かった
- 違うなと思うところ
- 型システムがカジュアルにできる
- C#は最初にごりごり型を決めてから書く感じ
- JavaScriptに引っ張られるところがあることに気がついた
- まわりにJavaScript嫌いって人が多くて、TSをオススメしにくくなった
- DDDがJSだけだと辛かった
- ドメインを型で表現するというのを気に入ってるので
チームにTSをどう導入していったか聞きたい
仕事でTSを使いたいなと思ったので、仕事でTSをどう導入していったか聞きたい。
- 自分はしれっと入れました。
- しれっとTSで作ってました。
- プロダクトではなくてツール的なものを
- その後任に人はTSやらないとですよね
- そうですね
- しれっとTSで作ってました。
- わがまま言ってTSを入れさせてもらった
- 少人数で意見が通りやすく、上司もDartをやったことがあるので寛容的な環境だった。
- 「JSは型が無いのに等しい言語だし、そもそもTSやらない理由がなくない」と言ったら賛成してもらえた。
- 長い目で見るのであれば、TSでしっかり型を付けて書いたほうがいいと思います。
- バグりにくく、リファクタリングしやすい
- TSの学習コストは掛かるけど、そのデメリットを上回る開発効率アップをアピールするしかないかな。
- 最終的にJSになるので、新言語とはちょっと違いますしね。
- 社内で使っているのは自分ひとりだけど、社内Wiki(esa)にちょこちょこTipsを投稿している。
- そうすると、数人は反応してもらえて、興味を持ってもらえる。
- まずは自分がある程度できるようにならないと布教もしづらいと思う。
- 入れた後って、周りの人にも勉強してもらわないとだめじゃないですか？
- 周りの人が書いたコードが全部 any になっちゃってたりする場合とかどうしてます？
- 最初は全部 any になってもいいんじゃないですか？
- おいおい慣れてきたら型をしっかりしていく
フロント開発環境、Docker使ってる？
- フロントエンドはDockerいらないかも
- 本番環境はブラウザなので
- Docker for Macはファイルシステムが遅いため、ソースコード更新をトリガーにしたジョブが遅くなりがち
- フロントの開発をしているが、Dockerは使ってない。
-
package.jsonにnodeのバージョンを指定できるのでそれで縛っておくこともできる - IOのボトルネックが厳しいので、フロントだけはホストというパターンもあるそうです
TS開発時の鉄板構成は何？
先日、TS何それ、という初学者向けに勉強会を開きました。そのとき以下を開発環境として紹介したのですが
もう古かったり？質問者はいまだにgulp, nodemonを使っているのですがもう天然記念物ですか？
- とりあえず脳死で ts-node (https://www.npmjs.com/package/ts-node)
- 鉄板
- ちょっと調べて ts-node-dev (https://www.npmjs.com/package/ts-node-dev)
- ソースコードに変更があったらリロードしてくれる
- 俺はgulp, nodemon (https://gulpjs.com/) (https://nodemon.io/)
- さくっと使うなら良い。使い込む場合難が出る場合あり
・・・
- denoですか？
- denoはまだいろいろと問題が多いので、それを乗り越える気合があるならいいかと……
- TSがそのまま動く。
- webpack
- gulpとかを駆逐して、webpack一度になった感が
- だがふくざつ
- parcel
- webpackの複雑さに対する反動的なzero configuration
- メジャーではないが、たまに見かける印象
- fuzebox はお亡くなりになったのだろうか
- tsc
- 最初はこれで。シンプル。
npm install -g typescript- tscたたいて、nodeで起動する
- 最初の1日目はこれでいい、2日目からts-nodeで。
- ts-node知ってから一度もtsc叩いてないかもw
Reactのclass component vs functional component
React Nativeでclass componentで書いてたら、functional componentに書き直されたので、その違いを聞きたい。
・・・
-
なぜ書き換えたか？書き換えた本人に聞いてみる
- hooksを使ってみたかったから。
- ステートレスなコンポーネントを作るときに、HOCなどのデザパタで解決していたが、functitonal componentはひとつの書き方で全部できるから
- ステートフルな書き方から、ステートレスな書き方に移行していったほうがいいと思ったから。
-
クラスコンポーネントなくなれってこと？
- クラスコンポーネントの書き方は今後も残るし、サポートされるけど、functional componentのほうが推奨という感じがある。
-
functional だと、「このコンポーネントでは状態を管理しませんよ」「データもらって表示する以上のことはしませんよ」という表明としても機能しそう
- 逆にclass 使うなら「ここでは状態持ちます」「ここで状態変化を持って、子コンポーネントへ伝播させます」ということになりそうで、状態無い場面でclassを使うと、読む人に不要なプレッシャーを与えそう（const で書ける変数をletで宣言してしまってる的な）
Reactってtsの型補完効くんですか？？Vue、あんまり効かなくてつらいです
- Reactってtsの型補完効くんですか？？Vue、あんまり効かなくてつらいです
- Vueよりは効きやすい感ある
- Vueもtemplateで補完を効かせる策が無いわけではない
- Vueじゃなくて、Vuexとテンプレートが型補完が聞かないのでは？
- 解決方法はいろいろある。だけど導入コストは高め
React NativeとExpo、どっちを使ったらいいか？
使ったことある人がいたら聞きたい。
・・・
- ケースバイケースな感じがあるが、Expoの場合はAppストア、Google Playへの公開まで面倒みてくれる。
- ネイティブモジュールはExpoでは作れないので、ネイティブ要件が出てきたら、EjectしてReact Nativeにできる
- Expoは、Appストアに公開しなくても、アプリを配布できる。
- Over-the-Airとは違う
フルサーバレスで実装している人がいたら、どういう感じで作っているか聞きたい (れおりん)
いませんでした。
フロントのパフォーマンスチューニング
フレームワークを使うより、素のJSで書いたほうが速いのか？
・・・
- Vanilla JSはジョークフレームワーク。普通のJSのこと。 - Qiita
- vanilajs って、なんでもjQueryの時代に対するアンチテーゼとして登場したもの、というイメージです
- jQuery直接ゴリゴリDOM弄っちゃうので、乱用したらまあ相当遅くなりますよね
- パフォーマンスチューニングが必要な複雑なGUIで、バニラJSでやるほうが大変な気が。
- web系はあまり経験ないのでわからないんですが、そこまでパフォーマンスが必要になるシーンてどんな時なんでしょうか？？
- vueとかでグリッドを導入していると、チューニングが必要になることも
- CSSのセレクターで重くなったり、一概にJSのせいにはならないかも
- vueとかでグリッドを導入していると、チューニングが必要になることも
- ページ読み込みは「2秒以内」に - 3秒待てないモバイルユーザー、画像圧縮で表示速度改善を | Beyond（ビヨンド）
パッケージと、そのパッケージの型定義のバージョニングを合わせたい
私的なプロジェクトではパッケージも、@typesも最新版を使うようにしていたためか気がつかなかったのですが、社で使っているNode.jsが古く、最新の@types/nodeを入れるとそのバージョンではまだ追加されていないメソッドが補完で出ているっぽいです。あるパッケージと、@typesのバージョンは合わせるためにはどうすれば？わかりやすいのはあるパッケージとその@typesが同じsemantic versioningをしてくれることですが、そんな保証ないですよね？
"A": "x.y.z",
"@types/A": "x.y.z"
- むずかしい。。。
- 公式のやつ使えば大丈夫かもしれないが、第3者が作ったやつだと難しい。
- 古いパッケージを上げるしかない
- peerDependencyが書いてあればよかったんですが……
マイクロサービスで困った経験談を聞かせて
マイクロサービスやったことあるひと？
・・・
- マイクロサービスって
- 機能ごとにサービスをわけて、それらを協調動作させてひとつのアプリにする。
- マイクロサービスとは
- マイクロサービスの対義語はモノリシックサービスですかね？
- 単純に、Monolithic だけですね。
フロントのプロジェクトでおすすめのアーキテクチャーがあれば教えてほしい。
- 絶賛模索中です。
- Flux + Containerのプレゼンテーションパターンを悩みながらやってる
- 一個のアーキテクチャが正解というのではなくて、
- ステートを管理するならFluxもあるし、最近はクリーンアーキテクチャも使われてるし、いろいろ組み合わせたりしていると思う。
- フロントだとデザイナーさんとの協業もあるので、デザイナーがいるいないでも、アーキテクチャが変わってくる
- 正解があるというわけではなく、状況に適したアーキテクチャを選ぶのがいいと思う。
- マイクロフロントエンドとかもありますしね。
- 課題を先に考えて、それに対するソリューションとしてアーキテクチャを選ぶのがまっとう。
参加してよかったこと(参加者の感想)
- そんな質問されても・・・みたいな質問でも皆さんで考えてもらえるところ
- 些細な質問に対しても、たくさんの返事をいただいたので良かったです。
- リモートでも参加可能なのがよかったです
- 経験豊富な方々の経験やツールの情報が効けたのがよかった
- TypeScriptだけでなく、アーキテクチャーやエンジニアにとって重要な情報が知られて事です。とにかく満足度は高いです。
- アーキテクチャの話はおもしろかった、というか共感できるポイントがあって嬉しかった
- 言語/技術に関係なくエンジニアにとって有用な知見が得られれたのがよかった（ドキュメンテーションの話とかアピールの話とか）
YYTypeScriptは毎週やってます
YYTypeScriptについてワイワイ話したい方は、YYTypeScriptのイベント情報をチェックしてみて下さい。
以上、YYTypeScriptのレポートでした。次回もワイワイやっていきたいと思います！ では、また来週！