React + TypeScript コンポーネントの既存の型を変更する時に考えること

こんにちは、Gaji-Labo フロントエンドエンジニアの鈴木です。
React + TypeScript を使ったフロントエンド開発でのコンポーネント実装時に、意識していることがいくつかあります。
今日はそのうちの一つ「React + TypeScript コンポーネントの既存の型を変更する時に考えること」について書いていきます。

型を変更する際に起こりうる事

一度 interface を定義したコンポーネントは、その前提で各箇所で使用されています。
コンポーネントの interface を変更するとなると、そのコンポーネントの使用箇所はもちろん、 Storybook やテストコードも修正することになります。
影響範囲が多岐にわたることが想像できますが、それが TypeScript で開発するメリットにも繋がるので、容易に軽視できない部分だと感じます。

型の変更でなければ対応できないのか再考する

過去の実例として、必須の Props として定義されていたものが、後になって Optinal な使われ方をすることが分かったコンポーネントがありました。
例を示すと、何かしらユーザーがオプションを選択することができて、それを受け取る selectedOptions があったとします。

interface Props {
  selectedOptions: Option[];
}

selectedOptions を Optional に変更すること自体は簡単です。

interface Props {
  selectedOptions?: Option[];
}

しかし前述の通り、既存の型を変更するとなると影響範囲が大きく、改修コストが掛かります。
そこでこのコンポーネントに関しては、 interface の定義は変えずに、 selectedOptions がない場合には空配列を渡す方法を採用しました。

<SomethingComponent selectedOptions={options || []} />

実際に使用するときはこのようになりました。

コンポーネントの interface を定義するときに

既存の型を変更したくなる場面はあまり多くないですが 「何が返ってくるか・何を受け取るか・それは必須なのか、実装のタイミングで FIX していないがコンポーネントは実装しないと間に合わない」 という場面はあります。
確定した段階で素早く型を変更することもそうですが、意図的に少し緩めに定義してあとで厳しくしたり、もしくは API 周りとのコミュニケーションが可能であれば、先にあるべき姿で型を定義することもあります。
これらはプロジェクトの状況やチーム体制などによって、どのような方針を取るかは変わってくると思います。
コンポーネント実装者として、interface を定義するときには後々の影響を考えた型定義ができるよう意識していきたいです。

Gaji-Laboブログ内には、他にもReact + TypeScript のコンポーネント開発の実践から得た知見を詰め込んだ記事があります。
React + TypeScript 、JavaScriptフレームワーク、コンポーネント開発、フロントエンド開発などに関わる記事をシリーズ「React + TypeScript のコンポーネント開発で得た知見」としてまとめていますので、あわせてお読みいただけるとうれしいです。