🦄✨ 未来の変更に備える！Compound Componentで実現する拡張性✨🦄

コンポーネントの悩み、解決したい！🎉

最近、たくさんの振る舞いを持つコンポーネントを開発しています⭐️ユーザーが入力した内容を検証したり、特定のボタンがクリックされたときにだけフッターを表示したり、状態によってヘッダーの表示を変えたり...。機能が増えるにつれて、コンポーネントに渡すpropsがどんどん増えコンポーネント内のロジックが複雑化し「これはprops地獄だ…😫」と頭を抱えていました。
ところで、propsを渡すことは本当に「地獄」なのでしょうか？
特定のドメイン（機能範囲）だけで完結する、深くネストされたコンポーネントツリーであれば、propsを渡していくprops drillingはまったく問題ありません。 Reactの基本的な仕組みだけでシンプルに実装でき、コードの流れも追いやすいからです。
しかし、そのコンポーネントの機能を拡張したり、一部の機能を使ったり使わなかったりする柔軟性が必要になった途端、propsの管理は複雑さを増します。例えば、モーダルのヘッダーやフッターをページによって表示・非表示を切り替えたいとき、showHeader={true}のようなpropsが雪だるま式に増え、if-elseの条件分岐が複雑化し、「props地獄」が現実のものとなります。
そんな時、Compound Component（複合コンポーネント）という魔法のパターンで、コードをスッキリ整理できることを再認識しました！このパターンを使えば、親コンポーネントが子コンポーネントの振る舞いを細かく制御する必要がなくなり、まるでコンポーネントの各パーツ（ヘッダー、本文、フッター）が自律的に動いているかのように扱えるんです。

このガイドでは、この魔法のパターンのヒミツを全部教えちゃいます。

魔法の呪文？ Compound Componentとは？ 🧙‍♀️

Reactのコンポーネントが増え、機能がゴチャゴチャしてくると、まるで絡まった毛糸玉みたいで大変ですよね。そんな時、Compound Componentという魔法のパターンが、コードをスッキリ整理してくれます！🎉

このパターンは、複数の小さな関連コンポーネントを、まるで仲良しグループのように1つの親コンポーネントにまとめます。Google Chromeのタブのように、親が司令塔となり、子コンポーネントがそれぞれの役割を果たすことで、UI全体が美しく機能するんです。

基本の構文

// 🏠 Detail コンポーネントという大きなお家
<Detail>
  <Detail.Header title="商品詳細" />  // 🚪 玄関（ヘッダー）
  <Detail.Body>コンテンツ</Detail.Body>  // 🛋️ リビング（本文）
  <Detail.Actions>                       // 🛠️ 作業スペース（アクションボタン）
    <button onClick={handleEdit}>編集</button>
    <button onClick={handleDelete}>削除</button>
  </Detail.Actions>
</Detail>

この構文は、コンポーネント同士の関連性を明確にし、UIの構造を視覚的にわかりやすくします。さらに、親コンポーネントが状態を内部で管理し、子コンポーネントと共有するため、状態管理がシンプルになります。

---

基本的なコンポジションとの比較：スーパーマン vs. ヒーロー戦隊 🦸‍♂️

普通のコンポーネント（基本的なコンポジション）は、まるで**「一人で何でもこなせるスーパーマン」**🦸‍♀️みたいです。
最初は頼もしいですが、機能が増えるごとにpropsという道具がどんどん増え、props地獄に陥りがち...😫

それに比べて、Compound Componentは**「チームで働くヒーロー戦隊」**🦸‍♂️💥です。

観点	スーパーマン（基本的なコンポジション）	ヒーロー戦隊（Compound Component）
構造の明確さ	自由度が高い	構造がハッキリ定義される 🎯
スタイルの一貫性	開発者任せ	コンポーネント側で保証 ✨
状態の管理	親で管理し、propsで渡す	内部で自動管理、Contextで共有 🧠
機能拡張	propsをどんどん追加…	新しいサブコンポーネントを追加するだけ！🥳
インポート	複数のインポートが必要	1つのインポートで完結 📦
props地獄	😱	サヨナラ！ 👋

---

魔法の作り方：ContextとTypeScript 🛠️

Compound Componentの魔法の杖は、**React ContextとTypeScript**です。

親コンポーネントは、Contextという魔法の箱🧙‍♀️を作って、そこに**「ダイアログが開いているか」や「アニメーションの状態」**といった共通の情報を入れておきます。

魔法の箱の設計図

// 💖 みんなで共有する魔法の箱の中身の設計図
type DialogContextType = {
  isOpen: boolean;
  isAnimating: boolean;
};

const DialogContext = createContext<DialogContextType | null>(null);

// 🕵️‍♀️ 魔法の箱から安全に中身を取り出すフック
export const useDialogContext = (): DialogContextType => {
  const context = useContext(DialogContext);
  if (!context) {
    throw new Error('Dialog components must be used within Dialog');
  }
  return context;
};

子どもたちは、親から直接propsを受け取る代わりに、この魔法の箱から必要なものを自由に引き出して使います。例えば、**Dialog.HeaderやDialog.Body**といった子コンポーネントは、この魔法の箱を使って親の状態にアクセスできます。

子コンポーネントの魔法の呪文

// 子コンポーネント：Dialog.Body
// 🔮 魔法の箱から必要な値だけ取り出す
export const DialogBody = ({ children }) => {
  const { isOpen, isAnimating } = useDialogContext();

  // ダイアログが開いていて、かつアニメーションが終了したら内容を表示する
  if (!isOpen || isAnimating) {
    return null;
  }

  return (
    <div className="dialog-body">
      {children}
    </div>
  );
};

このように、子コンポーネントは親から明示的にisOpenやisAnimatingといったpropsを受け取る必要がありません。Contextが魔法のように必要な情報を自動で届けてくれるのです。

さらに、TypeScriptで魔法の箱の中身をしっかり設計しておけば、型安全性が保証され、エディタが自動で強力な型補完をしてくれます。これで、タイプミスやバグがグッと減りますよ！🚀

---

スッキリ整理術：ファイル構成とアーキテクチャ 🏠

プロジェクトの規模に応じて、コンポーネントを整理する場所を決めましょう。

1. 汎用的なコンポーネント（推奨）
誰でも使える共通UIは、src/common/components/tabs/のように、機能ごとに1つのフォルダにまとめます。

src/common/components/tabs/
├── index.ts             # エクスポートを一箇所に集約
├── Tabs.tsx             # 親コンポーネント
└── ...子コンポーネントたち

index.tsでまとめてエクスポートすれば、**たった1行のimport**で全部の部品を呼び出せるので、とっても便利！

2. ドメイン固有のコンポーネント
特定の機能（商品、ユーザーなど）に特化したUIは、src/domain/product/components/ProductDetail/のように、ドメインごとに整理します。これにより、チームや機能の担当が明確になり、大規模なプロジェクトでも迷子になりません。

---

責任分担：誰が何をやるの？ 🎯

Compound Componentの最大の魅力は、**「責任の明確な分離」**にあります。

• ページコンポーネント（pages）：

  • ビジネスロジック（データの取得や送信など）に集中します。
  • UIの状態管理は、Compound Componentに任せます。

• Compound Component（common/components）：

  • UIの状態管理や振る舞いを担当します。
  • 「タブがクリックされたらコンテンツを切り替える」といったUIロジックをカプセル化します。

• ドメインロジック（domain/hooks）：

  • useProductのように、業務ロジック（商品データの取得、認証など）を担います。

これにより、ページはUIの複雑な振る舞いを気にせず、本来の仕事（データの表示）に専念できるようになります。テストもそれぞれ独立して書けるので、開発効率が大幅にアップします。📈

---

魔法の柔軟性：必要な部分だけ使っていいの？ 💖

Compound Componentは、**「必要な部分だけを自由に選んで使える」**という驚きの柔軟性を持っています。

フル機能版

<Card>
  <Card.Header>タイトル</Card.Header>
  <Card.Body>本文</Card.Body>
  <Card.Footer>フッター</Card.Footer>
</Card>

ヘッダーなし版（Headerを書かないだけ！）

<Card>
  <Card.Body>本文</Card.Body>
  <Card.Footer>フッター</Card.Footer>
</Card>

propsでshowHeader={false}と書く必要はありません！使わない要素は書かなければいいだけなので、コードがとってもシンプルになります。

順序の変更や複数使用も自由自在！

<Card>
  <Card.Body>本文を先に！</Card.Body>
  <Card.Header>タイトルを後に！</Card.Header>
</Card>

また、外部から制御したい場合も、propsを渡すだけで簡単に対応できます。Compound Componentは、内部の状態管理だけでなく、外部からの制御にも対応できるんです。

---

最終奥義：Compound Component + Custom Hooks ✨

最も強力なのは、Compound ComponentとCustom Hooksを組み合わせることです。

• Compound Component → 標準UIを提供します。
• Custom Hooks → UIから独立したロジックを提供します。

これにより、開発者は2つの選択肢を得られます。

1. 簡単さ重視：Compound Componentを使って、統一されたUIで迅速に開発する。
2. 柔軟性重視：Custom Hooksを使って、ロジックだけを再利用し、UIは自由にデザインする。

この組み合わせは、あなたの意図である「汎用的な機能を拡張しやすくする」ことに完璧に応えます。共通のロジックをフックにまとめることで、様々なUIで同じ振る舞いを実現できます。

---

まとめ：Compound Componentの素敵なところ💖

利点	説明
責務の分離	ページはデータの表示、コンポーネントはUIの振る舞い、フックは業務ロジックに集中。役割が明確になり、保守性がアップ！
デザインの一貫性	構造とスタイルを統一し、デザインシステムの構築に最適。アクセシビリティも自動で確保できます。
開発効率の向上	props地獄を回避し、コードの重複を排除。チーム分担も明確になり、バグが減少します。
驚きの柔軟性	必要な部分だけを使い、順序を自由に変えられます。不要なpropsで悩むことはもうありません！

Compound Componentパターンは、適切に使うことでReactアプリをより美しく、強く、そしてメンテナンスしやすいものに変える魔法です。プロジェクトの規模や要件に合わせて、この強力なパターンを賢く使いこなしましょう！💪✨