Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
タグ付きユニオン型を便利に使うテクニックとその注意点
Search
uhyo
November 28, 2025
Technology
1.2k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
タグ付きユニオン型を便利に使うテクニックとその注意点
2025-11-28 プロによる本気の攻略本『JavaScript/TypeScript実力強化書』 - Forkwell Library #115
uhyo
November 28, 2025
More Decks by uhyo
See All by uhyo
Reactの設計論
uhyo
24
15k
型があると何が嬉しいか
uhyo
3
150
Baseline対応のDOMの型定義を作った
uhyo
3
960
AIのReact習熟度を測る
uhyo
2
1k
React、まだ楽しくて草
uhyo
7
5.1k
TypeScript 7.0の現在地と備え方
uhyo
6
3.8k
React 19時代のコンポーネント設計ベストプラクティス
uhyo
20
11k
型定義でAIと会話する:型を通じてAIに意図を伝えるテクニック
uhyo
1
120
ECMAScript仕様の最新動向: プロセスの変化と仕様のトレンド
uhyo
3
980
Other Decks in Technology
See All in Technology
リアーキテクチャ後の障害ゼロを目指したShadow Testingの取り組み
nihonbuson
PRO
1
170
AIに賢く動いてもらうためのコンテキスト〜Snowflake女子会 vol.8
snowwmn0824
0
170
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
3
1.2k
.NET WebAssemblyで実現するクライアントサイドAI推論:NuGetからViteまで、2つのエコシステムを繋ぐビルド戦略
yamachu
1
660
絵ではじめるKubernetesセキュリティ
aoi1
5
710
Issue 駆動でスペシャリストの意図を届ける、AI 実装のアクセシビリティ向上
thkt
0
140
C#未経験の僕がAIに読めるコードを書かせるまで
maguroalternative
0
250
AI 時代のスタートアップエコシステ厶から考究する技術的負債との向き合い方
m3m0r7
PRO
3
2.6k
Why Agent Cost Needs Observability
nttcom
0
150
登壇の自信を奪う3匹のオバケ / 3 Ghosts That Rob You of Your Confidence in Public Speaking
pauli
9
1.1k
積み重なった技術負債への挑戦 〜初手としての全社ゴト化〜
techtekt
PRO
0
1.6k
Mastering Agentic Development: Harness Engineering for Effective Coding Agents
konippi
2
430
Featured
See All Featured
Building AI with AI
inesmontani
PRO
1
1.2k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
500
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
3k
4 Signs Your Business is Dying
shpigford
187
23k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
830
Mobile First: as difficult as doing things right
swwweet
225
10k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Between Models and Reality
mayunak
4
460
Six Lessons from altMBA
skipperchong
29
4.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Code Reviewing Like a Champion
maltzj
528
40k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
530
Transcript
タグ付きユニオン型を便利に使う テクニックとその注意点 2025-11-28 プロによる本気の攻略本『JavaScript/TypeScript実力強化書』 - FL#115
発表者紹介 uhyo 株式会社カオナビ フロントエンドエキスパート 仕事ではずっとJavaScript/TypeScript一筋。 2
第4章では 私の担当分では、タグ付きユニオン型を強力な 設計パターンとして紹介しました。 3
This Talk 今回は、タグ付きユニオン型のさらなる応用例 として、?: neverを使うテクニックを解説します。 ただし、このテクニックには注意点もあるので、 そちらも合わせて持ち帰りましょう。 4
タグ付きユニオンの例 type Success<T> = { success: true; value: T };
type Failure<E> = { success: false; error: E }; type Result<T, E> = Success<T> | Failure<E>; Result型の値rに対しては、r.successがtrueか falseかを見ればどちらの型なのか判別できる。 5
不便な点 絶対にsuccessをチェックしないとresultやerrorに アクセスできない。 6 // これはOK if (r.success) { console.log(r.value);
} // これはだめ const { success, value } = r; if (success) { console.log(value); }
不便な点 絶対にsuccessをチェックしないとresultやerrorに アクセスできない。 7 // これはOK if (r.success) { console.log(r.value);
} // これはだめ const { success, value } = r; if (success) { console.log(value); } successをチェックする前はvalue が存在するかどうか確定していない ので、アクセス不可
不便な点を解消するテクニック type Success<T> = { success: true; value: T; error?:
never }; type Failure<E> = { success: false; error: E; value?: never }; type Result<T, E> = Success<T> | Failure<E>; 8
不便な点を解消するテクニック 「もう一つの型に存在するフィールド」も、 ?: neverで指定しておくテクニック。 これは、「指定不可」という意味を表す。 (exactOptionalPropertyTypesコンパイラオプションを オンにしていない場合は、undefinedを指定することも可能) 9
指定不可とは 「型に書かれていない」 → 何が入っているか不明 (何かが入っている or 何も入っていない) 「指定不可」 → 何も入っていないことを保証
10
具体例による比較 type Success<T> = { success: true; value: T };
{ success: true, value: 123 } ←OK { success: true, value: 123 , error: “aaa” } ←これもOK 11
具体例による比較 type Success<T> = { success: true; value: T; error?:
never }; { success: true, value: 123 } ←OK { success: true, value: 123 , error: “aaa” } ←これはエラー 12
「指定不可」の活用 なんと、?: never を付けておくとこれがOKになる。 13 const { success, value }
= r; if (success) { console.log(value); }
「指定不可」の活用 OKになる理由: valueが未知の何かである可能性が 無くなったから。 • Successの場合: valueはT型 • Failureの場合: valueはundefined型(何も入っていないので)
14 const { success, value } = r; if (success) { console.log(value); }
「指定不可」の活用 しかも、このように分割代入してからif文等で型を 絞り込むことができる。(TS 4.6から) 15 const { success, value }
= r; if (success) { console.log(value); } ←ここではvalueはT | undefined ←ここではvalueはT
?: neverの利点まとめ SuccessとFailureの両方にvalueを明記しておくこと で、型を絞り込む前からアクセス可能になる。 しかも、タグ付きユニオン型の利点はキープ。 これにより、コードの書きやすさが向上。 16
?: neverの欠点 タグ付きユニオン型の絞り込みの方法が曖昧に なってしまうこと。 17 // 望ましい方法 if (r.success) {
console.log(r.value); } // こんなやり方もできてしまう if (r.value !== undefined) { console.log(r.value); }
?: neverの欠点 絞り込む手段としてsuccessを用意していたのに、 他の方法で絞り込む余地が生まれてしまう。 これは不注意によるバグや将来の変更によるバグの原因と なってしまう。 (3つ目のユニオンが追加されたときに意図しない条件分岐になっ てしまうまど) 18
まとめ ?: never というテクニックを使うことでタグ付き ユニオンをもっと便利に使うことができる。 しかし、状況を見て使うかどうか決めよう。 場合によってはバグの温床となってしまう危険性も。 19