⚛️

Next.js App Router 基礎

モダンなWeb開発のデファクトスタンダードであるNext.js App Routerのレンダリングやデータフェッチ、キャッシュの仕組みを図解で学びます。

学習をスタートする

🗺️ ロードマップ

1

Server Components と Client Components

Next.js App Router の最大の特徴は、Reactの最新機能である React Server Components (RSC) に完全対応している点です。 第1章では、サーバーとクライアントでコンポーネントがどのように役割分担をしているのか、そしてどのように画面が描画されるのかを図解で学びます。 1. 2つのコンポーネントの基本概念 Next.js App Router では、コンポーネントはデフォルトで Server Components(サーバーコンポーネント) になります。必要に応じて Client Components(クライアントコンポーネント) と明示的に指定して使い分けます。 特徴 Server Components (RSC) Client Components (RCC) デフォルト はい (App Router) いいえ ( が必要) 実行場所 サーバー側のみ サーバー側(初期ビルド時)& クライアント側 JSバンドルサイズ 0 (ブラウザにJSが送信されない) ブラウザに送信される(容量が増える) 対話性・状態管理 不可 (, 等は使えない) 可能 (状態やイベントリスナーを使用) データ取得 データベースやAPIへ直接セキュアにアクセス可能 通常はAPI経由でアクセス 2. サーバーサイドレンダリングの流れ(図解) コンポーネントがブラウザに届き、画面が表示されるまでの仕組みです。 1. サーバー側: 全ての Server Components を実行し、ブラウザが即座に表示できる「初期HTML」と、Reactの状態を復元するためのデータ「RSC Payload」を生成します。 2. ブラウザ側: * まず、JavaScriptの読み込みを待たずにHTMLをパースし、高速に初期画面を表示します。 * その後、ダウンロードしたJavaScriptを実行し、静的なHTMLに対してイベントハンドラーなどを結合(ハイドレーション)して、ページを操作可能な状態にします。 3. の正しい理解(境界の引き方) Client Components を使う場合は、ファイルの最上部に ディレクティブを記述します。 注意すべきなのは、 を記述したファイルとそのファイルからインポートされるすべての子コンポーネントが自動的に Client Components になる という点です。 推奨されるコンポーネント設計(境界の最小化) 不要なJavaScriptをブラウザに送らないよう、Client Components は「必要な部分だけ」に最小化するのがベストプラクティスです。 まとめ * Next.js App Router は、Server Components がデフォルト。余計なJSを削減し表示を高速化する。 * 対話性(状態管理、イベントハンドラー)やブラウザ専用APIが必要な部分だけ、最上部に を付けて Client Components にする。 * サーバーでプレビュー(HTML)を作成して高速に表示し、後からJavaScriptを結合(ハイドレーション)することで、表示速度と機能性を両立している。 次は、Next.jsでのデータの取得方法と、それをキャッシュして表示を極限まで高速化する仕組みについて学びましょう!

2

ルーティングとデータフェッチ・キャッシュ

Next.js App Router では、フォルダ構造がそのままルーティングになり、コンポーネントの中で非常にシンプルにデータをフェッチできます。さらに、ページの読み込み速度を最大化するために強力なキャッシュ機構が備わっています。 第2章では、App Router のルーティング構造、データ取得方法、そして複雑な「4つのキャッシュ」について図解で解説します。 1. App Router のルーティング構造 フォルダ名がURLパスになり、そのフォルダ内に配置する特別なファイル名によって役割が決まります。 ***: そのルートの固有UI(ページ本体)。 ***: 複数のページで共有されるUI(ヘッダー、サイドバーなど)。再レンダリングされず状態が維持されます。 ***: ページの読み込み中に表示されるローディングUI(自動的にReact Suspenseでラップされます)。 ***: エラー発生時に表示される代替UI。 2. Server Components でのデータフェッチ RSC(Server Components)では、コンポーネント自体を 関数にすることで、 や を使ったフックなしで直接データを非同期で取得できます。 3. Next.jsの「4つのキャッシュ」と判定フロー(図解) Next.jsには、パフォーマンス向上とAPIへの負荷を減らすため、4つの独立したキャッシュシステムが存在します。 キャッシュの概要 キャッシュ名 対象 保存場所 目的 Request Memoization 同一リクエスト内の 重複 サーバーメモリ 1回のリクエスト中で同じAPI呼び出しをまとめる Data Cache 異なるリクエスト間のAPIデータ サーバーのディスク/メモリ データベースやAPIのデータを保存して再利用する Full Route Cache ページ全体のHTMLとRSC Payload サーバーのディスク ビルド時や初回アクセス時に静的にページを丸ごと生成する Router Cache 画面遷移時のページデータ ブラウザメモリ ユーザーが画面遷移する際の待ち時間をゼロにする データ取得とキャッシュ判定フロー キャッシュの制御方法 開発者は のオプションでキャッシュの挙動をコントロールできます。 まとめ * App Router はフォルダ名がルーティングになり、 や を組み合わせてページを組み立てる。 * Server Components では を用いて、サーバー上で直接かつ安全にデータを取得可能。 * Next.jsの 4つのキャッシュ は、ブラウザ(Router Cache)からサーバーのAPI取得(Data Cache)まで細かく連携し、高速化とサーバー負荷の軽減に貢献している。

3

ルーティングとレイアウト(Layouts & Templates)

Next.js App Routerでは、ファイルシステムをベースとした直感的なルーティングと、状態を維持できる入れ子(ネスト)状のレイアウトシステムが採用されています。 第3章では、フォルダー構成がどのようにページURLに対応するのか、そして画面全体を効率的に構成するためのレイアウトやテンプレート、ルートグループの仕組みを図解で解説します。 1. ファイルシステムベースのルーティング App Routerでは、 ディレクトリ内のフォルダー構造がそのままURLパスになります。 ページとして公開するルートには、必ずフォルダー内に (または )を配置する必要があります。 * 動的ルーティング (): フォルダー名をブラケットで囲む(例: や )ことで、動的なURLパラメータ(例: )を受け取るページを作成できます。 2. レイアウト(Layout)とテンプレート(Template) 画面を構築する際、ヘッダーやサイドナビゲーションなどの「共通UI」を定義するために と を使用します。 レイアウト(Layout)の特徴 * 状態の維持 (State Preservation): ユーザーが子ルート間で遷移しても、レイアウトは再レンダリングされず、レイアウト内の状態(入力フォームの値やスクロール位置など)が維持されます。 * DOMの再作成なし: 遷移時にレイアウト部分のHTML要素は破棄されず、効率的に再利用されます。 テンプレート(Template)の特徴 * 毎回リセットされる: レイアウトと似ていますが、ルート遷移するたびにテンプレート内のインスタンスが新しく作成され、状態はリセットされます。 * ユースケース: ページ遷移ごとのフェードインアニメーションや、アクセス解析のページビュー計測( の再実行)を行いたい場合に適しています。 3. ルートグループ(Route Groups) 「URLのパス名には影響を与えたくないが、特定のページ群だけに共通のレイアウトを適用したい」または「ファイルを論理的なグループで整理したい」という場合には、ルートグループ を使用します。 フォルダー名を丸括弧で囲む(例: や )ことで、そのフォルダー名はURLのパスから除外されます。 具体例 以下のようにフォルダーを構成すると、URLは や になりつつ、それぞれ異なるレイアウトを適用できます。 * (認証画面用のシンプルなレイアウト) * → URLは /login * (ヘッダーやサイドナビ付きの標準レイアウト) * → URLは /dashboard 4. コードで見る Layout の基本構造 ルートレイアウト()は、アプリケーションの最上位でHTMLタグやBodyタグを定義する必須のファイルです。 レイアウトをネスト(入れ子)にすることで、無駄な再レンダリングを防ぎながら、美しく一貫性のあるユーザーインターフェースを構築できます。次のステップでは、このルーティングと密接に関わるデータ取得(Data Fetching)の仕組みを学んでいきましょう!