Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
タグ付きユニオン型を便利に使うテクニックとその注意点
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
uhyo
November 28, 2025
Technology
1.1k
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
7
4.1k
TypeScript 7.0の現在地と備え方
uhyo
6
3.3k
React 19時代のコンポーネント設計ベストプラクティス
uhyo
20
9.7k
型定義でAIと会話する:型を通じてAIに意図を伝えるテクニック
uhyo
1
84
ECMAScript仕様の最新動向: プロセスの変化と仕様のトレンド
uhyo
3
900
TypeScript 6.0で非推奨化されるオプションたち
uhyo
18
8.3k
Claude Code 10連ガチャ
uhyo
4
1.1k
AI時代、“平均値”ではいられない
uhyo
8
10k
意外と難しいGraphQLのスカラー型
uhyo
5
1.2k
Other Decks in Technology
See All in Technology
LLMを「主役」にしないための 3つの原則
techtekt
PRO
0
120
noUncheckedIndexedAccess、3時間、1万円。 / noUncheckedIndexedAccess, 3 Hours, 10,000 JPY.
kaonavi
1
320
Claude code Orchestra
ozakiomumkj
3
990
「気づいたら仕事が終わっている」バクラクAIエージェント本番運用の裏側 / layerx-bakuraku-aie2026
yuya4
19
11k
Databricks 月刊サービスアップデート 2026年05月号
tyosi1212
0
210
GoとSIMDとWasmの今。
askua
3
510
個人最適 から 全体最適 へ AI情報共有会・AIギルド・AI-DLC で進める カンリーの組織展開
rfdnxbro
0
1.8k
Agentic Defenseとともにセキュリティエンジニアが輝き続けるには / How Security Engineers Can Keep Excelling with Agentic Defense
yuj1osm
0
120
Amazon Bedrock AgentCore ワークショップ JAWS UG TOHOKU / amazon-bedrock-agentcore-workshop-jawsug-tohoku-2026
gawa
8
390
実装は速くなった、レビューはどうする? ― 自身のレビューをAIで再現させるサーヴァントエンジニアリングのすゝめ / Implementation got faster. So what about reviews? — An invitation to Servant Engineering: Recreating your own code reviews with AI
nrslib
7
4.1k
製造業のクラウド活用最適解〜AI,DXを加速するデータ基盤の作り方〜
hamadakoji
0
400
Sony_KMP_Journey_KotlinConf2026
sony
2
210
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
570
Designing Experiences People Love
moore
143
24k
Discover your Explorer Soul
emna__ayadi
2
1.1k
Skip the Path - Find Your Career Trail
mkilby
1
140
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
200
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
160
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
720
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
130
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
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