大規模なコードベースの改修のために自作TypeScriptツールを作るメリット
- 鴻巣 和司さん
大規模コード改修
- 大規模な改修の課題
- 差分がたくさん出る
- 開発期間が長い
- レビューでの実装漏れ見落とし
- コンポーネントライブラリのリプレース
- 自作の置換ツールを作った
- ルールに沿った一括置換
- 参照されないコンポーネントの削除
- Reactのコードで副作用が無いコードだからできた
- 一括でできるからいろいろなアプローチを試せた
- ts-morph使ってAST操作した
- ツールを作ってみて
- 汎用性にこだわらずプロヘクト特化した方がいい
- 80%の自動化を目指して20%は主導で
ReactNative アプリ同士の通信のために型情報をサクッと共有した話
ReactNativeでアプリ間通信
- 飲食店で使うシステムを作ってる
- 障害が起きた時に店内のローカルネットワークだけで稼働し続けないといけない
- ReactNatveのアプリ間でTCPの通信をする
- レジとハンディ端末間
- 型を揃えることでネットワークを超えても直接呼び出してるかのように動かす
- rollup-plugin-dtsで型を生成
私のことは嫌いになってもTypeScriptのことは嫌いにならないでください
- Fumiya Konnoさん
TypeScriptがなぜ必要か
- JSでTODOアプリ作ってTS化してみた
- エラーがたくさん出て潜在的に良くないコードがわかる
- TSならランタイムエラーにならない
- 型がドキュメントになる
- TypeScript上級者へ
- 型エラーの解消
- 型の定義
- 変数や型から型を作る
テスト用のオブジェクトを簡単につくれるFactoryJSというライブラリを作った
- ktmoukさん
FactoryJS
vanilla-extractを使った型安全なmodule.cssの実現
- おさささん
Next.jsのAppRouter
- RSCをお使うとRuntime CSS in JSが使えない
- zero runtimeなCSSへの移行の流れ
- runtime css
- JS実行時にCSSを生成
- zero runtime css
- ビルド時にCSSを生成
- vanilla-extractを採用した
- CSSが型安全
- class名の型チェック
- recipeを使うとemotionと同じようなことができる
- CSSが型安全
tsconfig.jsonの設定を見直そう！ フロントエンド向け 2024夏
- うひょさん
tsconfig.json
- tsconfig.json
- moduleResolution
- baseUrl
- もういらない
- 4.0以前でpathsを設定するために必要だった
./から始まらないのに相対パスで扱ってしまう弊害も
- target
- es5やesnextなどを書ける
- コードの実行環境のバージョンを指定する機能
- そのバージョンのJSにトランスパイルする
- lib指定してるとそっちが優先される
- 実際の動作環境を表す値をいれるといい
- libも
- module
- どんなモジュールシステムで動くか指示する
- targetからモジュールシステムだけ抜き出した設定
- esnextを指定するとトランスパイル先がES Modulesだという意味
- moduleResolutionがbundlerだとesnextかpreserveの2択
- preserveはimportとrequire両方使える
- Webpackとかbunで両方使える場面があるので
