component-organization

フロントエンドコンポーネントの構成

これは参考パターンです。 このアプローチを参考にし、状況に合わせて応用してください。文章をそのままコピーしないでください。

問題：フロントエンドプロジェクトが大きくなると、ディレクトリが整理されず、関連ファイルを見つけにくくなり、共有コードの置き場所も明確でなくなります。

解決策：種類（コンポーネント、フック、ライブラリ、型）ごとに整理し、各種類の中で関連項目をまとめるサブディレクトリを作成します。

---

パターン

frontend/
├── app/                 # Framework routing (Next.js app dir, Nuxt pages, etc.)
│   ├── layout.tsx
│   └── page.tsx
├── components/          # All components
│   ├── ui/              # Base primitives (Button, Input, Modal)
│   ├── UserProfile.tsx
│   ├── DashboardChart.tsx
│   └── PostCard.tsx
├── hooks/               # Custom hooks
│   ├── use-auth.ts
│   ├── use-dashboard.ts
│   └── use-debounce.ts
├── lib/                 # Utilities, services, business logic
│   ├── api/             # API client, fetch helpers
│   ├── auth/            # Auth context, cookie handling
│   └── utils/           # Pure helper functions
├── queries/             # Data fetching (GraphQL queries, API calls)
├── types/               # Shared type definitions
│   ├── user.ts
│   └── post.ts
└── public/              # Static assets

主なルール：

• コンポーネントはcomponents/に配置し、関連するものはサブディレクトリ（例：ui/）にまとめます
• フックはhooks/に配置し、1ファイルにつき1つのフックを定義します
• ビジネスロジックはlib/に配置し、ドメイン別のサブディレクトリにまとめます
• ファイル間で共有する型はtypes/に配置します
• 基本UIプリミティブ（ボタン、入力欄、モーダル）はcomponents/ui/に配置します

---

このパターンを使う理由

メリット：

• 予測しやすい：どこを見ればよいかが明確です。すべてのフックはhooks/に、すべてのコンポーネントはcomponents/にあります
• 再利用性：複数の機能で使われるコンポーネントを見つけやすく、共有も簡単です
• スケーラビリティ：新しいフックやコンポーネントを追加する際の置き場所が明確です
• コンポーネントライブラリに自然に適合：共有UIキットの構成方法と一致します

種類ごとのサブディレクトリを使う場合：

• components/ui/ — どこでも再利用される基本プリミティブ
• lib/auth/ — 1つのドメインに複数のファイルがある場合（コンテキスト＋ユーティリティ＋型）
• lib/api/ — APIクライアント、インターセプター、ヘルパー

---

分割するタイミング

• components/に新しいファイルを作成：UIを再利用する場合、または親コンポーネントが約200行を超える場合
• hooks/に新しいファイルを作成：ステートフルなロジックを再利用する場合、またはコンポーネントが煩雑になる場合
• lib/に新しいサブディレクトリを作成：あるドメインに関連ファイルが2つ以上ある場合（サービス＋ユーティリティ、コンテキスト＋ヘルパー）
• components/ui/に移動：ビジネスロジックを持たない、純粋なプレゼンテーション用コンポーネントの場合

---

段階的な改善

開発者が、このスキルで防げるはずの振る舞いを修正した場合は、今後同じ修正が必要にならないよう、このスキルに加える具体的な修正案を提案してください。