腕利きエンジニアのための `Extract
こんにちは。日々、コンパイラの機嫌を取りながら、巨大なコードベースの型安全性を担保することに情熱を燃やしているフロントエンド・チーフアーキテクトです。
今回は、TypeScriptの組み込みユーティリティ型の中でも、一見地味ながら極めて強力な破壊力を秘めた `Extract
「ユニオン型から特定の型を抽出するやつでしょ？」
そう思ったあなた。半分正解ですが、半分はエンジニアとしての底が浅いです。`Extract
今回は、この `Extract` を極限まで使い倒し、ワンランク上の型安全なアーキテクチャを構築する方法を、ブラウザエンジンやコンパイラの内部挙動に少し触れながら紐解いていきましょう。
—
1. `Extract` の基本と、コンパイラの内部挙動
まずは基本のおさらいです。公式ドキュメント的な定義を振り返りつつ、TypeScriptのコンパイラが裏で何をやっているのかを覗いてみます。
type Extract
このシンプルな条件付き型（Conditional Types）の裏側で、TypeScriptの型チェッカー（Tsc）は、ユニオン型 `T` の各要素をバラバラにして（これを分散条件付き型 / Distributive Conditional Typesと呼びます）、それぞれが `U` に割り当て可能（assignable）かどうかを判定しています。
- 割り当て可能なら、そのままの型（`T`）を残す。
- 割り当て不可なら、無の象徴である `never` に変える。
- 最後に、生成されたユニオン型（`T | never` は `never` が自動的に消去されるため）を合体させる。
この「分散する」という挙動こそが、`Extract` の本質です。単一の型を突っ込むのではなく、ユニオンという「状態の集合」に対してフィルターをかける操作なのだと認識してください。
—
2. なぜ `Extract` が実務で不可欠なのか？
大規模なフロントエンド開発（例えば、複雑な状態管理を持つRedux ToolkitやZustandのActions、あるいは複雑なAPIレスポンスのDiscriminated Unions）において、私たちは常に「型の絞り込み（Narrowing）」の地獄と戦っています。
ここで、安易に `any` や `unknown` を使って逃げたり、不必要な型アサーション（`as` キャスト）を多用したりすると、アプリケーションのどこかで爆弾が破裂します。
リアルなユースケース：イベント駆動アーキテクチャの型安全なフィルタリング
次のような、UIコンポーネントから発火する多様なアクションのユニオン型を考えてみましょう。
type UIEvent =
| { type: ‘click’; payload: { x: number; y: number } }
| { type: ‘focus’; payload: { targetId: string } }
| { type: ‘blur’; payload: { targetId: string } }
| { type: ‘keydown’; payload: { key: string } };
ここで、「キーボード関連のイベントだけを処理するハンドラー」を作りたいとします。愚直に書けば `Extract` の出番です。
// ‘keydown’ イベントの型だけを美しく抽出する
type KeydownEvent = Extract
// 結果としての型:
// { type: ‘keydown’; payload: { key: string } }
const handleKeydown = (event: KeydownEvent) => {
// ここでは完全に絞り込まれているため、余計なガードを書く必要がない
console.log(event.payload.key);
};
これの何が素晴らしいか？
将来、`UIEvent` に新しいイベント（例えば `’keyup’`）が追加されたとき、もしハンドラー側で適切に型を追従させ忘れても、`Extract` はコンパイルタイムで静的にミスマッチを検出してくれます。ランタイムのエラーを未然に防ぐ、これぞTypeScriptアーキテクチャの醍醐味です。
—
3. 高度な応用：APIレスポンスのステータス管理とメモリ/パフォーマンスの最適化
ここからが本題です。さらに踏み込んで、複雑な非同期処理の状態管理において `Extract` をどう活用するかを見ていきます。
非同期処理では、`Idle`, `Loading`, `Success`, `Error` という状態（State）をユニオン型で表現することが多いでしょう。
type ApiState
| { status: ‘idle’ }
| { status: ‘loading’; progress: number }
| { status: ‘success’; data: T; cachedAt: number }
| { status: ‘error’; error: Error };
ここで、コンポーネントのレンダリング負荷を最適化するため、`success` 状態のときだけ特定の重いデータをメモリ上に展開し、不要なプロセスの再計算を防ぎたいとします。
このとき、`Extract` を用いて「特定のステータスに紐づくデータ構造」だけを抽出するユーティリティ型を定義します。
// 指定したステータスに合致するAPIステートのサブセットを抽出する汎用型
type ExtractApiState
// 成功時の型だけをピンポイントで取り出す
type SuccessState
パフォーマンスとメモリ効率への配慮
「型定義がパフォーマンスにどう影響するのか？」と疑問に思うかもしれません。実は、巨大なTypeScriptのコードベースにおいて、複雑すぎる条件付き型や不必要なジェネリクスのネストは、TypeScript言語サーバー（tsserver）のメモリ消費量を激増させ、エディタのサジェスト遅延（入力カクつき）を引き起こします。
ブラウザのレンダリング負荷とは直接関係ありませんが、開発体験（DX）という名の開発者のCPU/メモリ効率をブーストするために、型はなるべくシンプルでプリミティブな構造に保つべきです。
`Extract
—
4. 陥りがちな罠：`Extract` が `never` に化ける瞬間
現場でよくある失敗談をシェアしましょう。次のようなコードを書いたとき、なぜか型が `never` になって頭を抱えるエンジニアが後を絶ちません。
type Primitive = string | number | boolean;
// やりがちなミス
type Result = Extract
「`string` が含まれているんだから、`string` が抽出されるはず！」と思いきや、結果は `string` になります（これは意図通り）。
しかし、次のようなオブジェクトのユニオン型ではどうでしょう。
type User =
| { id: number; role: ‘admin’ }
| { id: number; role: ‘user’ };
// うっかりプロパティの型を間違えた場合
type AdminUser = Extract
// 結果: never
`super-admin` なんて値はユニオンの中に存在しないため、コンパイラは容赦なくすべてを `never` に叩き落とします。
もしあなたが「型が存在しない場合はデフォルトのフォールバック型を返したい」と考えているなら、単体での `Extract` では不十分です。次のようなガードを組み合わせる必要があります。
// 抽出結果が never になる場合の安全なフォールバック機構
type SafeExtract
Extract
type SafeAdmin = SafeExtract
// 結果: { id: 0; role: ‘guest’ }
このような「型安全の安全ネット」をアーキテクチャの基盤（Common Typesなど）に仕込んでおくことで、API仕様の変更や予期せぬ型ミスマッチによるコンパイルエラー（あるいはそれを無理やり `as any` でねじ伏せる悪習）を防ぐことができます。
—
5. まとめ：型は「ドキュメント」であり「契約」である
今回は `Extract
単に動くコードを書くだけなら、`any` や `as` を使えば一瞬で終わります。しかし、私たちが目指すべき「堅牢なWebアプリケーション」とは、コードの変更がドミノ倒しのように予期せぬバグを生む恐怖から解放され、コンパイラを最強の味方につけた開発環境のことにほかになりません。
`Extract
それでは、良きTypeScriptライフを。
コメント