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では、JavaScriptフレームワーク経験が豊富なパートナーさんを募集しています

Gaji-Laboでは、開発チームの一員としてプロジェクトに一緒に取り組んでくれる業務委託のパートナーさんを募集しています。

現在は特にJavaScriptフレームワーク実践と業務経験が豊富なWebフロントエンドエンジニアを必要としています。React + TypeScript、Vue.js、Next.js、Nuxt.js など、あなたの得意なフレームワークを教えて下さい!

パートナー契約へのお問い合わせもお仕事へのお問い合わせも、どちらもいつでも大歓迎です。まずはオンラインでのリモート面談からはじめましょう。ぜひお気軽にお問い合わせください!

お問い合わせしてみる!

投稿者 Gaji-Labo Staff

Gaji-Laboの社内デジタル環境でいろいろなお手伝いをしているがじ専務&じら常務。みんなのシリーズ記事をまとめたり、卒業したスタッフの過去記事を記録したり、Twitterをやったりしています。