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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
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
26
17k
型があると何が嬉しいか
uhyo
3
160
Baseline対応のDOMの型定義を作った
uhyo
3
1k
AIのReact習熟度を測る
uhyo
2
1.1k
React、まだ楽しくて草
uhyo
7
5.2k
TypeScript 7.0の現在地と備え方
uhyo
6
3.9k
React 19時代のコンポーネント設計ベストプラクティス
uhyo
20
11k
型定義でAIと会話する:型を通じてAIに意図を伝えるテクニック
uhyo
1
120
ECMAScript仕様の最新動向: プロセスの変化と仕様のトレンド
uhyo
3
990
Other Decks in Technology
See All in Technology
DevelopersIO 2026 知識の地図を描く ─ オントロジーとは何か?
ishikawa_satoru
1
1.5k
全PRの83%が AIレビューだけでマージできるようになった開発組織は その後どうなったか @2026/10
athug
0
140
DGX Spark でどこまでハッキングができるのか?
kash1064
0
750
しろおびから始める!ログ活用の第一歩
shumei_ito
0
900
AgentCoreで実践するハーネスエンジニアリング
yakumo
1
300
ai_cording_with_k8s_knowledge.pdf
mochizuki875
1
340
Classmethod Company Deck
satoshi7
0
110
AI時代のPRレビューにどう向き合うか?
kairim0
1
200
ゲームのリアルタイム通信から見た QUIC と MoQ
segadevtech
0
110
Essential architectural thinking (revised edition)
ufried
0
110
二歩目のフロントエンド・ウェブアクセシビリティ
camiha
2
380
Snapshot Testing in Practice: Predictable and Reliable SwiftUI Views
fespinoza
0
190
Featured
See All Featured
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
69
67k
Site-Speed That Sticks
csswizardry
13
1.6k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
Designing for humans not robots
tammielis
254
26k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
74
42k
The World Runs on Bad Software
bkeepers
PRO
72
12k
Evolving SEO for Evolving Search Engines
ryanjones
0
320
Utilizing Notion as your number one productivity tool
mfonobong
4
620
Leo the Paperboy
mayatellez
10
2.4k
For a Future-Friendly Web
brad_frost
184
10k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.4k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
540
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