nextjs

Next.js

Next.js App Router（14 以降）のプロジェクト内規約です。作成または変更するコードに適用してください。依頼がない限り、変更されていないルートは移行しないでください。

規約

• App Router のみを使用します。 pages/ に追加してはいけません。プロジェクトにまだ pages/ がある場合、新しい作業は app/ に追加し、誰かが移行を予定するまでは両方を共存させます。
• デフォルトではサーバーコンポーネントを使用します。 'use client' は、ページではなくインタラクティブ性が必要なリーフを示します。このマーカーより上にあるものはすべてブラウザーにも配信されるため、境界は可能な限りツリーの深い位置に置きます。
• キャッシュの動作は、インストールされているバージョンに照らして確認します。 動作は変更されています。Next 14 までは fetch はデフォルトでキャッシュされ、キャッシュを無効にする設定が必要でした。Next 15 以降では、fetch、Route Handlers、クライアントナビゲーションはデフォルトでキャッシュされず、キャッシュを有効にする設定が必要です。デフォルトを誤って想定すると、ページが古いままになるか、オリジンにすべてのリクエストが送られることになります。package.json を確認し、デフォルトの動作に頼るのではなく、意図を明示的に設定します（cache、next.revalidate、またはルートセグメント設定）。
• Next 15 以降、params と searchParams は Promise です — const { slug } = await params。14 を前提に書かれたコードでは同期的に分割代入するため、アップグレード時に動作しなくなります。どちらの形式を使う場合も、まずインストールされているメジャーバージョンを確認してください。
• layout.tsx の認証チェックはセキュリティ境界ではありません。 レイアウトは子ルート間のナビゲーションごとに再レンダリングされないため、クライアント側の遷移ではチェックがスキップされることがあります。ミドルウェア内と、データを読み取る箇所の両方でアクセスを制御します。レイアウトでのチェックは UX のためのものであり、アクセス制御ではありません。
• 取得するデータにはタグを付け、タグで再検証します。 next: { tags: ['user'] } と、ミューテーション後の revalidateTag('user') を組み合わせると、影響を受けるデータだけを無効化できます。時間ベースの再検証は古さについての推測ですが、タグはそれを明確に示します。
• Server Actions は公開エンドポイントです。 アクション ID を見つけられる人なら誰でもアクセスできるため、すべてのアクションで認証を再確認し、サーバー側で入力を再検証します。フォームがレンダリングされた状態で表示されていたとしても、呼び出し元の正当性を証明するものではありません。
• データをレンダリングするコンポーネントで取得します。 React は同一のレンダーパス内で同一のリクエストを重複排除するため、「重複」する取得を避けるためにデータを props で下層に渡しても効果はなく、ツリーの結合度を高めるだけです。
• Metadata API を通じてメタデータを設定します — export const metadata または generateMetadata を使用します。コンポーネント内に手書きした <head> タグはネストされたレイアウト間でマージされず、フレームワークのメタデータに暗黙のうちに置き換えられます。
• 常に next/image と next/font を使用します。 これらは、レイアウトシフトの原因となるサイズ未指定の画像と、初回描画を妨げるフォント読み込みという、Core Web Vitals の主なコストに対処するためのものです。生の <img> を使うと、その両方の利点を失います。
• 意味のあるルートセグメントごとに loading.tsx と error.tsx を用意します。 失敗はルート境界で処理するべきです。error.tsx がないと、あるセグメントのエラーによって、そのセグメントを囲むレイアウトまで機能しなくなります。