React + TypeScript のコンポーネント開発で interface を書く時ときに意識していること

suzuki

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

例えばこのような Props を想定していた場合

errorType が何かしらの string で渡ってくることが分かっていた場合、このように定義することができます。

interface Props {
  errorType: string;
}

しかし、 errorType が既にいくつかの種類で決まっていた場合は、より詳細に型を定義することができます。
例えば payment mailAddress phoneNumber のいずれかの文字列だと分かっていた場合は、以下のように定義することも可能です。

interface Props {
  errorType: 'payment' | 'mailAddress' | 'phoneNumber';
}

errorType: string より詳細に表せるのであれば、 'A' | 'B' | 'C' のように Union Types で定義するのが良いと考えています。

  • この Props で何を受け取るかがより明確になる
  • なるべく入り口を狭くすることで想定されたものだけ受け取るようになる

Union Types

Union Types を使用すると上記の例以外にも、string と number のどちらかが渡ってくる Props に対して foo: string | number のような使い方もできます。

Union Types に関する詳しい仕様はこちらをご参考ください。 https://www.typescriptlang.org/docs/handbook/advanced-types.html#union-types

おわりに

React + TypeScript での開発では、主に各画面に使われるようなコンポーネント実装を多く受け持っています。
小さな1つのボタンコンポーネントから少し大きめのリストコンポーネントなど粒度は様々ですが、各画面に使われるからこそ「より適した型定義にできないかな?」と考えながら実装するようにしています。

引き続き、React + TypeScript でのコンポーネント開発で得た知見をブログにしていきたいと思います。

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

Gaji-Laboでは、JavaScriptフレームワーク経験が豊富なパートナーさんを募集しています

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

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

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

お問い合わせしてみる!


suzuki

投稿者 suzuki

HTML/CSS のマークアップから始まり、現在は React や TypeScript を使ったコンポーネント実装をすることが多いです。

淡々と実装するだけではなくコミュニケーションを取りながら、チームとしてプロジェクトを前に進めることを意識しています。

最近は会社の成長へのコミットに関心があり、組織・チーム全体で強まるためにはどうするのだろう?ということを考えています。