やあ、今日もコードと向き合ってくれてお疲れさん。
中級へのステップを駆け上がっている君なら、そろそろ「既存の型をいい感じに使い回して、コピペ職人から卒業したい」というフェーズに差し掛かっている頃じゃないかな。
TypeScriptのプロジェクトが大きくなってくると、APIのレスポンス定義や巨大なコンポーネントのPropsに苦しめられる。その時、君の救世主になってくれるのがユーティリティ型だ。中でも今回は、実務で毎日と言っていいほどお世話になる `Pick
マニュアル通りの退屈な説明は抜きにして、現場のリアルな泥臭さと共にその真髄を紐解いていくよ。
—
そもそも `Pick` とは何か？
一言で言えば、「巨大な型（お弁当箱）から、自分が今本当に必要な具材（プロパティ）だけをつまみ食いして、新しい型を作るための魔法のツール」だ。
基本の構文はこうだ。
type 新しい型 = Pick<元の型, 抽出したいキーのユニオン型>;
「なんだ、ただの型エイリアスとどう違うんだ？」と思ったかい？
ここが重要なポイントなんだけど、`Pick` を使う最大の理由は「単一情報源の原則（DRY原則）」を型レベルで守るためにある。元の型 `T` が改修されたとき、`Pick` を使っていれば自動的に新しい型も追従してくれる。これがコピペコードとの決定的な違いであり、保守性を保つためのシニアの知恵なんだ。
ブラウザやコンパイラの内側では何が起きているのか？
少しだけ裏側の話をしよう。TypeScriptの型システムは、JavaScriptのランタイムではすべて消え去る。ブラウザが実行するのは、あくまであの泥臭いJavaScriptだ。
じゃあ、コンパイル時にTypeScriptのコンパイラ（`tsc`）は何をしているのか？
実は、`Pick
コンパイラの脳内を覗いてみよう。`Pick
type Pick
[P in K]: T[P];
};
これ、めちゃくちゃエレガントじゃないか？
1. `K extends keyof T` で、「指定したキーは、大元の型 `T` に存在するものだけ許すよ」という強い型安全の制約をかける。
2. `[P in K]` で、指定されたキーのユニオン型をループ（反復）させる。
3. `T[P]` で、元の型からそのプロパティの型をごっそり持ってくる。
つまり、ブラウザが動く前のビルドの瞬間に、コンパイラはこの定義を展開して、綺麗な新しいオブジェクトの型をパズルのように組み立て直しているんだ。JavaScriptの実行パフォーマンスには1ミリも影響しない。型安全という名の「開発者のための安全ネット」を、ノーコストで構築できるってわけさ。
—
【実践】実務で使えるコピペ可能なコード例
百聞は一見にしかず。実務でよくある「ユーザー管理画面」を想定したコードを見てみよう。
エディタを開いて、そのままコピーして試してみてくれ。
/
- バックエンドから返ってくる巨大なユーザー情報の型
- （実際の現場では、API仕様書や自動生成された型ファイルに相当します）
/
interface User {
id: string;
name: string;
email: string;
age: number;
address: string;
isAdmin: boolean;
createdAt: string;
}
/
- —————————————————————-
- パターン1: ユーザー一覧のテーブル表示用に、必要な情報だけを抽出する
- —————————————————————-
- 画面の一覧には、id, name, email, isAdmin 以外は不要だとします。
- 不要なプロパティを削るために Pick を使います。
/
type UserSummary = Pick
// 実戦投入の例
const displayUser: UserSummary = {
id: “usr_001”,
name: “山田 太郎”,
email: “yamada@example.com”,
isAdmin: false,
// age: 30, <- ここで 'age' を入れようとすると、TSコンパイラが「そんなプロパティないよ！」と怒ってくれます
};
/
- —————————————————————-
- パターン2: プロフィール編集フォームの送信データ用型を作る
- —————————————————————-
- ユーザーが自分で変更できるのは name と address だけだとします。
- これも Pick の独壇場です。
/
type UserProfileUpdatePayload = Pick
const handleUpdate = (payload: UserProfileUpdatePayload) => {
// APIに送信する処理…
console.log(“Updating:”, payload);
};
handleUpdate({
name: “山田 次郎”,
address: “東京都渋谷区…”,
});
どうだい？これなら「もし将来、`User` 型に `phoneNumber` が追加されたとしても、関係ない画面の型に影響を与えずに済む」というメリットが肌で感じられたんじゃないかな。
—
シニアが教える、現場でやりがちなアンチパターンとベストプラクティス
最後に、現場で後輩のコードレビューをしているときによく見かける「惜しいポイント」を共有しておこう。
❌ やりがちなアンチパターン: Omitで引き算しすぎる
「大元の型から、不要なものを削りたい！」と思ったとき、ついつい `Omit
削るプロパティの数が残すプロパティより多い場合、これは悪手だ。仕様変更で新しいプロパティが増えたときに、意図せず隠したい機密情報などがうっかり画面側に露出してしまうセキュリティリスクすら孕む。
⭕ ベストプラクティス: 「残したいもの」を明示的に Pick する
セキュリティや正確性が求められるフロントエンド開発では、「必要なものだけをホワイトリスト方式で Pick する」ほうが圧倒的に安全だ。APIの仕様変更に強く、コンポーネントが本当に依存しているデータ構造がコード上から一目でわかるようになる。
—
まとめ
`Pick
使いこなせばこなすほど、無駄な型定義の重複が消え、コードベースが美しく洗練されていくのが実感できるはずだ。まずは今日のタスクの中で、「あ、ここコピペの型定義になってるな」という場所を見つけて、こっそり `Pick` に置き換えてみてほしい。
君のコードが、より洗練されたものになることを楽しみにしているよ。それじゃ、次のコードレビューでまた会おう！
コメント