83. データモデルの型設計 — interfaceは画面の設計図

APIから受け取るデータには、必ず interface で型を付けます。HttpClient の get<Product[]>() のように型を渡せば、フィールド名の打ち間違いや存在しないプロパティへのアクセスを、実行前にエディタとコンパイラが指摘してくれます。型はデータの設計図であり、画面とAPIの間の契約書です。

慣れてきたら「APIの型」と「画面用の型」を分けるタイミングも意識します。最初は1つの型で十分ですが、画面のために計算した値(税込価格や表示用ラベルなど)を足したくなったら分け時です。APIの型はサーバーの都合、画面用の型は表示の都合で変わるので、混ぜると両方の変更に振り回されます。

初学者が逃げたくなるのが any です。any にすればエラーは消えますが、それは問題が消えたのではなく「壊れるのが実行時に先送りされた」だけです。undefined の画面表示や本番でのエラーとして返ってきます。型を書く数分の手間は、実行して壊れる場所を探す数時間より必ず安く付きます。

サンプルコード(フレームワーク環境が必要なため表示のみ)

// APIレスポンスの設計図を interface で書く
export interface Product {
  id: number;
  name: string;
  price: number;       // 税抜価格(APIが返す単位に合わせる)
  stock: number;
}

// HttpClient に型を渡すと、以降の扱いがすべて型チェックされる
// this.http.get<Product[]>('/api/products')
//
// products[0].nama  → コンパイルエラー(打ち間違いに即気付ける)
// products[0].name  → OK
//
// any で逃げた場合:
// (products[0] as any).nama → エラーにならず、画面に undefined が出る
// 壊れる場所がコンパイル時から実行時に先送りされるだけ

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗