mcpField
N
nextjs-best-practices

nextjs-best-practices

github.com/davila7開発33.0k630 回インストール1 日前に更新
リポジトリ

nextjs-best-practices について

nextjs-best-practices は、Next.js App Router を使う開発者向けの開発指針をまとめたスキルです。コンポーネント、データ取得、ルーティング、キャッシュ、パフォーマンスを扱います。

主な機能

  1. 01Server／Client Components の選択
  2. 02データ取得とキャッシュ戦略
  3. 03App Router のルート構成
  4. 04API ルートハンドラーの指針
  5. 05パフォーマンスとメタデータの最適化

活用シーン

  1. 01App Router のプロジェクト構成を計画
  2. 02サーバーとクライアントの実行先を選択
  3. 03リクエストのキャッシュと再検証を設定
  4. 04API ルートと Server Actions を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/davila7/claude-code-templates --skill nextjs-best-practices

インストール後、Claude Code で/nextjs-best-practicesを入力して読み込まれたか確認します。

詳細

Next.js ベストプラクティス

Next.js App Router 開発の原則です。

1. サーバーコンポーネントとクライアントコンポーネント

判断ツリー
Does it need...?
│
├── useState, useEffect, event handlers
│   └── Client Component ('use client')
│
├── Direct data fetching, no interactivity
│   └── Server Component (default)
│
└── Both? 
    └── Split: Server parent + Client child
デフォルトの方針
種類用途
サーバーデータ取得、レイアウト、静的コンテンツ
クライアントフォーム、ボタン、インタラクティブな UI

2. データ取得パターン

フェッチ戦略
パターン用途
デフォルト静的（ビルド時にキャッシュ）
RevalidateISR（時間ベースの再生成）
No-store動的（リクエストごと）
データフロー
ソースパターン
データベースサーバーコンポーネントでのフェッチ
APIキャッシュ付き fetch
ユーザー入力クライアントの状態 + サーバーアクション

3. ルーティングの原則

ファイル規則
ファイル用途
page.tsxルートの UI
layout.tsx共有レイアウト
loading.tsxローディング状態
error.tsxエラーバウンダリ
not-found.tsx404 ページ
ルートの構成
パターン用途
ルートグループ (name)URL に影響させずに整理
パラレルルート @slot同じ階層の複数ページ
インターセプト (.)モーダルオーバーレイ

4. API ルート

ルートハンドラー
メソッド用途
GETデータの読み取り
POSTデータの作成
PUT/PATCHデータの更新
DELETEデータの削除
ベストプラクティス
  • Zod で入力を検証する
  • 適切なステータスコードを返す
  • エラーを適切に処理する
  • 可能な場合は Edge ランタイムを使用する

5. パフォーマンスの原則

画像の最適化
  • next/image コンポーネントを使用する
  • ファーストビュー内の画像には priority を設定する
  • ぼかしのプレースホルダーを用意する
  • レスポンシブな sizes を使用する
バンドルの最適化
  • 重いコンポーネントは動的インポートにする
  • ルート単位のコード分割を利用する（自動）
  • バンドルアナライザーで分析する

6. メタデータ

静的と動的
種類用途
静的エクスポート固定のメタデータ
generateMetadataルートごとの動的なメタデータ
必須のタグ
  • title（50〜60 文字）
  • description（150〜160 文字）
  • Open Graph 画像
  • Canonical URL

7. キャッシュ戦略

キャッシュのレイヤー
レイヤー制御
リクエストfetch のオプション
データrevalidate/tags
ルート全体ルートの設定
再検証
方法用途
時間ベースrevalidate: 60
オンデマンドrevalidatePath/Tag
キャッシュなしno-store

8. サーバーアクション

ユースケース
  • フォームの送信
  • データの変更
  • 再検証のトリガー
ベストプラクティス
  • 'use server' を付けてマークする
  • すべての入力を検証する
  • 型付きのレスポンスを返す
  • エラーを処理する

9. アンチパターン

❌ 避けるべき例✅ 推奨
どこにでも 'use client'デフォルトはサーバー
クライアントコンポーネントでフェッチサーバーでフェッチ
ローディング状態を省略loading.tsx を使用する
エラーバウンダリを無視error.tsx を使用する
大きなクライアントバンドル動的インポート

10. プロジェクト構成

app/
├── (marketing)/     # Route group
│   └── page.tsx
├── (dashboard)/
│   ├── layout.tsx   # Dashboard layout
│   └── page.tsx
├── api/
│   └── [resource]/
│       └── route.ts
└── components/
    └── ui/

覚えておくこと: サーバーコンポーネントがデフォルトなのには理由があります。まずはそれを使い、必要な場合にのみクライアントを追加してください。

コメント

Markdown 対応