NextJS 13 フォルダ構成
Next.js 13のApp Routerでは、新しいフォルダ構造やルーティングシステムが導入され、効率的なプロジェクト管理が可能になりました。本記事ではベストプラクティスを紹介します。
重要ポイント
/app
ディレクトリはルート専用に最適化- フォルダ命名規則で役割を明確化
- ルートグループで関連ページを整理
問題点
Next.js 13のApp Router導入時に以下の点で混乱が生じます:
- ログイン/登録ページの配置場所
- コンポーネントの整理方法
- 関連コンポーネントのグルーピング
- ルーティング構造の明確化
- ファイル配置によるチームメンバーへの意図伝達
解決策
基本原則
bash
my-project/
├── src/ # 推奨: アプリコードの分離
│ ├── app/ # ルーティング専用
│ ├── components/ # 全コンポーネント
│ ├── lib/ # ユーティリティ
│ └── services/ # API通信(オプション)
├── public/
├── next.config.js
└── package.json
1. /app
ディレクトリの活用
ルーティング専用に使用し、内部をシンプルに保ちます:
bash
src/app/
├── (auth)/ # ルートグループ
│ ├── login/
│ │ └── page.tsx # /login
│ ├── register/
│ │ └── page.tsx # /register
│ └── layout.tsx # 認証共通レイアウト
├── dashboard/
│ └── page.tsx # /dashboard
├── (admin)/ # 管理者用グループ
│ └── settings/
│ └── page.tsx # /admin/settings
└── layout.tsx # グローバルレイアウト
注意
ルートグループ(括弧()
で囲んだフォルダ)はURLパスに含まれず、以下の用途で有用です:
- 共通レイアウトの共有
- 関連ルートの論理的分離
- 認証状態によるルーティング制御
2. コンポーネントの整理方法
bash
src/components/
├── common/ # 汎用コンポンネント
│ ├── Button.tsx
│ └── Card.tsx
├── auth/ # 認証関連
│ ├── LoginForm.tsx
│ └── RegisterForm.tsx
├── dashboard/ # ダッシュボード固有
│ ├── Widget.tsx
│ └── Chart.tsx
└── ui/ # UI プリミティブ
├── Alert.tsx
└── Dialog.tsx
3. /lib
ディレクトリの活用
bash
src/lib/
├── constants.ts # 定数管理
├── types.ts # TypeScript型定義
├── utils.ts # 汎用関数
├── validators.ts # バリデーション
└── fonts.ts # フォント設定
高度な構成テクニック
プライベートフォルダの使用
非ルート関連ファイルには_
プレフィックスを付加:
bash
src/app/
├── _components/ # ルート用コンポーネント
├── _hooks/ # カスタムフック
├── _providers/ # プロバイダー
└── (routes)/
└── marketplace/
└── page.tsx
ルートグループの活用パターン
tsx
export default function AuthLayout({
children,
}: {
children: React.ReactNode
}) {
return (
<div className="auth-container">
{/* 認証ページ共通のUI */}
{children}
</div>
)
}
推奨構成例
bash
src/
├── app/
│ ├── (auth)/
│ │ ├── login/
│ │ │ └── page.tsx
│ │ ├── register/
│ │ │ └── page.tsx
│ │ └── layout.tsx
│ ├── dashboard/
│ │ └── page.tsx
│ ├── _components/ # ルート固有コンポーネント
│ ├── _test/ # ルート関連テスト
│ └── layout.tsx
├── components/
│ ├── common/
│ ├── ui/
│ └── shared/
├── lib/
│ ├── utils.ts
│ ├── types.ts
│ └── constants.ts
├── services/ # API通信層
├── stores/ # 状態管理(Zustand等)
└── styles/ # グローバルスタイル
ベストプラクティス
- 一貫性の維持: チームで命名規則を統一
- 分離の原則:
- ルーティング:
/app
- 表示層:
/components
- ビジネスロジック:
/lib
,/services
- ルーティング:
- スケーラビリティ: 機能追加時に迷いのない配置を
- 自己文書化: フォルダ名で意図を明確化
公式ドキュメント:
上記構造で開発効率と保守性を大幅に向上させられます。プロジェクト規模に応じて柔軟に段階適用してください。