TSKaigi Kansai 2024

型システムでどれだけ難しい問題を解けるか

有限オートマトン懐かしい

どれだけ難しい問題まで解けるかを計算機モデルと比べることで論じる

• 有限オートマトン
  • 自身の状態だけで解ける問題
  • 正規表現と同等
• プッシュダウンオートマトン
  • スタックあり
• チューリングマシン
  • 無限長テープの利用
  • 現状最も難しい問題の解ける計算機モデル

TSの型システムだけでチューリング完全になる

チューリング完全である=繰り返し、条件分岐、順次実行ができる

• 繰り返し -> 再帰
• 条件分岐 -> Indexed Access Types でアクセスすることで switch-case 的な分岐ができる
• 順次実行 -> 再帰でできる

再帰上限はある

停止性問題の話おもしろい

• チューリングマシンは停止性問題(その入力が停止するかを判定する)を解けない
• スマートコントラクトではガス代がかかるので止まらないプログラムがかけることが一般的な言語より致命的→意図的にチューリング不完全にしている

型チェックの時間が 40.21s -> 23.77s に改善
型チェックだけで40秒ってすごいな...

Redux Toolkit の型推論の時間が80%

const state: {
  count: number
} = {
  count: 0
}

で型定義部分に名前をつけてあげることでキャッシュが聞きやすくなって速度が改善した

type State = {
  count: number
}

const state: State = {
  count: 0
}

Extract で抽象化していたものを関数のオーバーロードで対応
他のパターンが増えないことがドメインとして見込まれていたので愚直にオーバーロードをNパターン用意しても良いよね、となった

いつか使うかなと思って定義だけしている型を消すことで改善

tsc の時間は上記の施策で改善したが、VSCode でのチェックはキャッシュが利用されないので VSCode 側はあまり改善しない

react-hook-form + zod のパターンが良く使われるけど、型の不一致がよく起こる

const schema = z.object({
    windowHeight: z.string().transform(Number)
})

const windowHeight = watch('windowHeight');
//	        ^? const windowHeight: number
console.log(typeof windowHeight);	// string

→ jotai を使ったフォームをやってみた

react-hook-form を使う理由、よりパフォーマスに優れた非制御コンポーネントでフォームを作れる点にある気がしてて、型との不一致も非制御だから難しいよねって話な気がするんよなー

制御コンポーネントで zod なりを噛ませたら安全ですはそれはそうな気がする

Parse, don't validate 良いエッセイだよね