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
13k
型があると何が嬉しいか
uhyo
3
140
Baseline対応のDOMの型定義を作った
uhyo
3
940
AIのReact習熟度を測る
uhyo
2
1k
React、まだ楽しくて草
uhyo
7
5k
TypeScript 7.0の現在地と備え方
uhyo
6
3.8k
React 19時代のコンポーネント設計ベストプラクティス
uhyo
20
11k
型定義でAIと会話する:型を通じてAIに意図を伝えるテクニック
uhyo
1
120
ECMAScript仕様の最新動向: プロセスの変化と仕様のトレンド
uhyo
3
960
Other Decks in Technology
See All in Technology
空間オーディオで過去の 自分(ゴースト)と競うランニング 〜HealthKitのルートを足音に変える実装〜
nao_randd
0
220
2026/09/10 Spring Bootから Jakarta EE/MicroProfileへの移行
megascus
0
370
あるけみー式LTスライド作成術
alchemy1115
1
210
アプリログインとWeb認証基盤をつなぐ ASWebAuthenticationSession 作法
shimastripe
1
320
GoにおけるFFIのこれまでとこれから
goccy
5
3.4k
Deploying a Full-Stack Bun-Native Framework on Cloudflare Workers
7nohe
0
170
ユーザー価値を届け続けるためにウォンテッドリーが大切にしている文化
kotaminato
0
160
Spring BootからQuarkusへの移行
tatsuya1bm
2
120
SREは、MCPとAutopilotをこう使え!
kazumax55
2
800
[2026-09-11]SREは誰のもの?運用エンジニアが始める 「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE
tosite
0
250
OpenTelemetry eBPF Instrumentationの舞台裏 / Behind the Scenes of OpenTelemetry eBPF Instrumentation
ymotongpoo
4
1.3k
AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先
nwiizo
0
2.6k
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
580
A Soul's Torment
seathinner
8
3.6k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
410
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
A Modern Web Designer's Workflow
chriscoyier
699
190k
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
410
Automating Front-end Workflow
addyosmani
1369
210k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
450
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
380
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