バランスを見極めよう！実装の意味を明示するための型定義 TSKaigi 2025 Day2 (5/24)

TSKaigi 2025 Day2 (5/24)

https://2025.tskaigi.org/talks/dinii

お知らせ:
https://diniinote.notion.site/Dinii-Engineering-EntranceBook-1df71045ad748062afe9c672363bdcab

Transcript

1. © 2025 Dinii Inc. TSKaigi 2025 Day2 (5/24) スポンサーセッション バランスを見極めよう！ 実装の意味を明示するための型定義 株式会社ダイニー Shota Hatada (@whatasoda)
2. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 自己紹介 2020 - 2022 SWE (Frontend) at mercari 2022 - Platform Engineer at Dinii Inc. Shota Hatada (@whatasoda) やっていること • Google Cloud を使ったインフラ整備 • NestJS / React Native アプリの基盤実装 • サービス安定性・拡張性向上に向けた活動 • いくつかのプロダクトのコードオーナー すきなもの/こと • TypeScript • Spa LaQua • アニメ・ゲーム（GW は Civ7 に消えました ^^）
3. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション はじめに 優秀な型推論の仕組みのお陰で… TypeScript は何かと記述を省略できる言語 JavaScript は引数を省略すれば undefined になるので…
4. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション はじめに 最初に実装したときに動いても、将来の変更で壊れることはある • 関数の呼び出し方が期待と異なる方法だったら…？ • 実装時の前提を崩すような変更が行われたら…？ 必要な箇所にだけ型を書くだけでも動く実装はできる。 でも、壊れにくい実装になっているだろうか？ 書き方次第ではこれらの問題を型エラーとして発見できないことも
5. 将来の変更に強くするために 型定義や実装で意識したいことがある
6. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション ラインナップ 1. 「Optional Parameter/Property」と「undefined 許容」を使い分ける 2. never 型への代入可否の判定で Union Types への網羅性を保証する 3. 明示的な型注釈で余計なプロパティが追加されることを防ぐ
7. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 1. 「Optional Parameter/Property」と「undefined 許容」を使い分ける 2. never 型への代入可否の判定で Union Types への網羅性を保証する 3. 明示的な型注釈で余計なプロパティが追加されることを防ぐ ラインナップ
8. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 「Optional Parameter/Property」と「undefined 許容」を使い分ける optional で定義した引数・プロパティは指定漏れの原因になりやすい。 「optional ( ?: のこと) 」と「undefined 許容」は振る舞いが異なる optional undefined 許容
9. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 「Optional Parameter/Property」と「undefined 許容」を使い分ける optional で定義した引数・プロパティは指定漏れの原因になりやすい。 「optional ( ?: のこと) 」と「undefined 許容」は振る舞いが異なる optional undefined 許容
10. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 「Optional Parameter/Property」と「undefined 許容」を使い分ける optional で定義した引数・プロパティは指定漏れの原因になりやすい。 optional undefined 許容 「optional ( ?: のこと) 」と「undefined 許容」は振る舞いが異なる
11. 株式会社 ダイニー © 2025 Dinii Inc. • 重要度の低い要素の振る舞いを変更できる • 重要度の低い要素の有無が切り替わる バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 「Optional Parameter/Property」と「undefined 許容」を使い分ける もちろん省略できて嬉しいときもある。重要度に合わせて使い分けていこう。 • 重要な要素に必要な情報だが fallback がある • 重要な要素の有無が切り替わる Optional Parameter/Property undefined 許容 ※ optional が適している場面もある。
12. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 1. 「Optional Parameter/Property」と「undefined 許容」を使い分ける 2. never 型への代入可否の判定で Union Types への網羅性を保証する 3. 明示的な型注釈で余計なプロパティが追加されることを防ぐ ラインナップ
13. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション never 型への代入可否の判定で Union Types への網羅性を保証する Union Types の評価の網羅性の保証を never への代入可否判定で実現する 動作確認しなくても実装漏れに気がつくことができる 1. エラーなどを適切に Union Types 化 2. Union Types の全パターンで Early Return/Throw 3. 網羅できていれば変数が never になるはず 4. 引数が never の関数を使って型チェックで保証する
14. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション never 型への代入可否の判定で Union Types への網羅性を保証する Union Types の評価の網羅性の保証を never への代入可否判定で実現する 動作確認しなくても実装漏れに気がつくことができる 1. エラーなどを適切に Union Types 化 2. Union Types の全パターンで Early Return/Throw 3. 網羅できていれば変数が never になるはず 4. 引数が never の関数を使って型チェックで保証する
15. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション never 型への代入可否の判定で Union Types への網羅性を保証する 正しく設計できていれば到達し得ない ⇒ Unreachable FYI: throw しないならこれでも OK
16. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 1. 「Optional Parameter/Property」と「undefined 許容」を使い分ける 2. never 型への代入可否の判定で Union Types への網羅性を保証する 3. 明示的な型注釈で余計なプロパティが追加されることを防ぐ ラインナップ
17. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 明示的な型注釈で余計なプロパティが定義されることを防ぐ 型注釈をつけると型チェックを厳しくできる 余計なプロパティを除外したい場合、 代入可否の判定だけでは型エラーにならない ことがあるので注意。 API によっては実行時にエラーになることも
18. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション パターンA: 事前に変数に定義してから代入する 明示的な型注釈で余計なプロパティが定義されることを防ぐ 余計なプロパティがあっても、期待する型を満たしているので型エラーにならない。（これ自体は正しい振る舞い）
19. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション パターンB: 代入と同時にオブジェクトを定義する 明示的な型注釈で余計なプロパティが定義されることを防ぐ 素のオブジェクト部分は型エラーになる。しかし配列の map などで型推論が挟まると通ってしまう。
20. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション パターンB: 代入と同時にオブジェクトを定義する 明示的な型注釈で余計なプロパティが定義されることを防ぐ 直に指定するプロパティでは型エラーになる。しかし、配列の map などで型推論を挟むと通る。
21. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション パターンB: 代入と同時にオブジェクトを定義する 明示的な型注釈で余計なプロパティが定義されることを防ぐ 素のオブジェクト部分は型エラーになる。しかし配列の map などで型推論が挟まると通ってしまう。
22. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション パターンC: B に加え、map に明示的な型注釈を入れる 明示的な型注釈で余計なプロパティが定義されることを防ぐ 型推論が挟まっているときでも、関数の戻り値などに明示的に型注釈を入れれば型エラーを出せる。
23. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション パターンD: 事前に型注釈つきで変数に定義してから代入する 明示的な型注釈で余計なプロパティが定義されることを防ぐ
24. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション パターンE: 余計なプロパティを型注釈に含める（なんと！エラーにならない！） 明示的な型注釈で余計なプロパティが定義されることを防ぐ
25. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション 明示的な型注釈で余計なプロパティが定義されることを防ぐ （そもそも面倒だよね…） すべてに型注釈をつけると冗長になることもある • API やストレージなど、アプリケーションプロセスの外部に渡す値 • 共通実装の関数の戻り値や状態の初期値など、多くの要素から参照される値 • その他、値の正確さを高めたい箇所 必要なタイミングを見極めて使っていこう Dinii Engineering EntranceBook https://diniinote.notion.site/1df71045ad748062afe9c672363bdcab \お知らせ/
26. 株式会社 ダイニー © 2025 Dinii Inc. バランスを見極めよう！実装の意味を明示するための型定義 ━━ TSKaigi 2025 Day2 (5/24) スポンサーセッション まとめ • 型チェックで異常検知ができない実装パターンがある • 初回実装時はよくても、将来の変更で怪しい実装になることも • 型定義の工夫すれば怪しい変更を型エラーとして検知できる 冗長さとのバランスを見極めつつ 将来の変更に強いコードをめざそう Dinii Engineering EntranceBook https://diniinote.notion.site/1df71045ad748062afe9c672363bdcab \お知らせ/