Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
タグ付きユニオン型を便利に使うテクニックとその注意点
Search
uhyo
November 28, 2025
Technology
1
120
タグ付きユニオン型を便利に使うテクニックとその注意点
2025-11-28 プロによる本気の攻略本『JavaScript/TypeScript実力強化書』 - Forkwell Library #115
uhyo
November 28, 2025
Tweet
Share
More Decks by uhyo
See All by uhyo
ECMAScript仕様の最新動向: プロセスの変化と仕様のトレンド
uhyo
1
65
TypeScript 6.0で非推奨化されるオプションたち
uhyo
15
5.7k
Claude Code 10連ガチャ
uhyo
5
900
AI時代、“平均値”ではいられない
uhyo
8
3.2k
意外と難しいGraphQLのスカラー型
uhyo
5
900
RSCの時代にReactとフレームワークの境界を探る
uhyo
13
4.4k
知られざるprops命名の慣習 アクション編
uhyo
12
3.3k
libsyncrpcってなに?
uhyo
0
730
Next.jsと状態管理のプラクティス
uhyo
7
17k
Other Decks in Technology
See All in Technology
DGX SparkでローカルLLMをLangChainで動かした話
ruzia
1
150
PostgreSQL で列データ”ファイル”を利用する ~Arrow/Parquet を統合したデータベースの作成~
kaigai
0
180
AIで加速する次世代のBill Oneアーキテクチャ〜成長の先にある軌道修正〜
sansantech
PRO
1
150
[続・営業向け 誰でも話せるOCI セールストーク] AWSよりOCIの優位性が分からない編(2025年11月21日開催)
oracle4engineer
PRO
1
160
DDD x Microservice Architecture : Findy Architecture Conf 2025
syobochim
13
6.7k
AI時代のインシデント対応 〜時代を切り抜ける、組織アーキテクチャ〜
jacopen
4
170
type-challenges を全問解いたのでエッセンスと推し問題を紹介してみる
kworkdev
PRO
0
140
20251127 BigQueryリモート関数で作る、お手軽AIバッチ実行環境
daimatz
0
350
Master Dataグループ紹介資料
sansan33
PRO
1
4k
Flutter Thread Merge - Flutter Tokyo #11
itsmedreamwalker
1
120
『ソフトウェア』で『リアル』を動かす:クレーンゲームからデータ基盤までの統一アーキテクチャ / アーキテクチャConference 2025
genda
0
2.1k
不確実性に備える ABEMA の信頼性設計とオブザーバビリティ基盤
nagapad
5
9.4k
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
186
22k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
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