Reactで学んだ共通コンポーネント設計の考え方
目次
この記事は誰に向けて書いたか
Reactを使い始めたばかりで、「ボタンやフォームを画面ごとに毎回書いている」「気づいたらコピペだらけになっている」と感じているエンジニアに向けて書きました。また、転職やキャリアチェンジを考えている方にも、実際の開発現場のエンジニアがどんなことを意識しながら日々コードを書いているのか、その空気感が少しでも伝われば嬉しいです。「即戦力じゃないと通用しないのでは」と不安に思う方もいるかもしれませんが、こうした試行錯誤の積み重ねこそが実務の中身だったりします。
最初はとにかく「動けばいい」だった
Reactでの開発を始めたばかりの頃、私は画面ごとに個別のコンポーネントを作っていました。ボタン、入力フォーム、モーダル（画面の上に重なって表示される小さなウィンドウ）……見た目が少し違うだけで、ほぼ同じようなコードをその都度書いていたのです。
当時は「とにかく画面が動けばOK」という感覚で開発を進めていました。1つの画面を作るごとに達成感があり、それはそれで悪くない経験だったと思います。ですが、画面数が増えるにつれて、ある日ふと気づきました。「これ、どこかで似たようなコードを書いた気がする」と。案の定、プロジェクト内を検索してみると、3〜4箇所で似たようなボタンのコンポーネントが、微妙に違う実装のまま存在していました。しかも、あるボタンだけ角の丸みが違っていたり、無効化（disabled）状態の見た目が統一されていなかったりと、細かいズレも見つかりました。
なぜ共通化が必要なのか
同じような処理を複数箇所で書いていると、次のような問題が起こります。
- 修正漏れが発生しやすい：デザインの色を変更したいとき、1箇所だけ直して他を直し忘れる
- コードの量が増え、可読性が落ちる：後から読む人（未来の自分も含む）が、どれが正しい実装なのか判断に迷う
- バグの温床になる：同じロジックなのに微妙に実装が違うと、挙動の差異が生まれ、思わぬ不具合につながる
- レビューコストが増える：似たようなコードが何度も出てくると、コードレビューをする側の負担も大きくなる
これはSPA（シングルページアプリケーション。ページ全体を再読み込みせずに画面を切り替えるWebアプリの構成）の開発において、特に起こりやすい問題だと感じています。画面遷移が多い分、似たようなUI部品を使い回す場面が多く、油断するとあっという間に「似て非なるコンポーネント」が量産されてしまうのです。
共通コンポーネント化で意識していること
共通化を進める際、私が意識しているのは次の4点です。
1. 「見た目」と「振る舞い」を分けて考える ボタンの色や大きさといった見た目の違いはprops（コンポーネントに渡す設定値のようなもの）で吸収し、クリック時の処理などの振る舞いは呼び出し側に任せる、という切り分けを意識しています。こうすることで、コンポーネント自体はシンプルなまま、使い方の自由度を保つことができます。
2. 早すぎる共通化はしない 「まだ2箇所しか使っていないのに、無理に共通化しようとして逆に複雑になった」という経験があります。共通化のためにpropsをどんどん増やしていった結果、そのコンポーネント自体が何をするものか分かりにくくなってしまったのです。個人的には、同じようなコードが3回以上出てきたタイミングで共通化を検討する、というくらいの感覚がちょうど良いと感じています。
3. 名前と置き場所にこだわる components/common のような共通コンポーネント用のディレクトリを用意し、名前だけで役割が分かるようにしておくと、チームメンバーが探しやすくなります。「何でも共通化フォルダに入れる」のではなく、本当に使い回されるものだけを置くようにすると、後から見返したときの見通しも良くなります。
4. ドキュメントより「使用例」を残す 細かい仕様書を書くよりも、実際にそのコンポーネントを使っているコードをサンプルとして残しておく方が、他のメンバーにとって分かりやすいと感じています。百聞は一見にしかず、というのはコードの世界でも同じだと実感しました。
共通化してみて変わったこと
実際に共通コンポーネント化を進めてみると、デザインの修正依頼が来たときの対応スピードが目に見えて上がりました。以前は「どこを直せばいいんだっけ」と探すところから始まっていましたが、共通化後は該当のコンポーネントを1箇所直すだけで済むようになりました。
また、チーム全体でも「新しい画面を作るときは、まずcommonフォルダを見に行く」という習慣ができ、無駄な重複コードが徐々に減っていきました。数字として測ったわけではありませんが、体感としてはコードレビューの時間も短くなったように感じています。
まとめ：完璧な設計より、まず気づくことが大事
共通コンポーネント設計に「絶対的な正解」はないと感じています。プロジェクトの規模やチームの人数、扱っているサービスの性質によっても最適な形は変わってきます。
大事なのは、最初から完璧な設計を目指すことではなく、「あれ、これ前にも書いたな」という違和感に気づき、少しずつ改善していく姿勢だと思います。最初は誰でも、動くものを作ることに精一杯です。そこから一歩進んで「このコード、もっと良くできるかもしれない」と考えられるようになったとき、開発者としての視野が少し広がった気がしています。この記事が、同じように試行錯誤しながらReactと向き合っている誰かの参考になれば嬉しいです。
