「静的・動的」はパスの形にも、ページを作る時点にも使われる。動的なURLも事前生成できるため、二つの軸を混ぜずに読む。
§ 00 · ルーティング — URLを画面につなぐ
ルーティングはブラウザのURLをどの画面につなぐか決めることだ。/aboutのようにURLの各部分が決まっているパスは固定パスである。/products/42のように値の一部がページごとに変わるパスは、動的セグメントを使い、一つの規則で複数のURLを処理する。
Next.js App RouterではフォルダがURLセグメントを作り、pageファイルがそのパスに表示するUIを作る。products/[id]/pageは/products/42と/products/99を同じページ規則で受け、idの値をparamsから読む。
§ 01 · 静的ルートと動的ルート
静的ルートは/aboutや/pricingのようにパスの各部分が固定される。動的ルートは[id]や[slug]のように名前を付けた位置に実際のURL値を受け、商品・記事・利用者などデータに応じた複数ページを表す。ここで動的とは、URL規則の一部が変数という意味だ。この違いは一般に静的ルーティングと動的ルーティングと呼ばれる。
フォルダを入れ子にするとURLも入れ子になる。/shop/[category]/[product]のように複数の動的セグメントを置ける。catch-allセグメントは後に続く複数の部分をまとめて受け取る。動的な値をそのまま信用せず、存在と形式を検査し、不正なURLには404を返す。
§ 02 · 移動しても共通の画面を残せる
Linkはアプリケーション内のパスへ移動するための仕組みだ。通常のリンクの意味とアクセシビリティを保ちながら、フレームワークが先読みとクライアント側の遷移を適用できる。URLを変えるボタンより、文書間の移動をリンクで表現するのが基本だ。
layoutは複数の子パスが共有するUIを包み、移動中も維持できる。loadingは待機中の画面、errorはエラー境界、not-foundは見つからないパスへの応答を担う。ルーティングはURL一覧だけでなく、移動・待機・失敗まで含む利用者の流れだ。
§ 03 · レンダリング — 画面をいつ、どこで作るか
クライアントレンダリング(CSR)はブラウザがJavaScriptを実行してUIを作る。サーバーレンダリング(SSR)はリクエストを受けたときサーバーがHTMLを作る。事前レンダリングはビルド時や再検証時にHTMLをあらかじめ作り、キャッシュする。一つのアプリケーションでも、ルートやコンポーネントに応じて方式を混ぜられる。
サーバーが作ったHTMLも、操作に反応するにはブラウザのJavaScriptがイベントを結び付ける必要がある。この処理をhydrationと呼ぶ。サーバーレンダリングとクライアント遷移は対立する選択肢ではなく、初期画面をサーバーから素早く見せ、その後の移動を滑らかにつなぐ形で併用する。
§ 04 · URLの形と生成の時点を混ぜない
動的ルートだからといって、必ずリクエストのたびにサーバーで作るわけではない。可能なslugやidの一覧がビルド時に分かれば、動的セグメントの複数ページを事前生成できる。逆にURLが固定されていても、リクエストのCookieや検索条件を読んで毎回動的にレンダリングできる。
「静的か、動的か」と聞かれたら、まず何を聞かれているか確かめる。URLパターンか、HTMLの生成時点か。この二つを分ければ、静的ルーティングと動的レンダリングのように似た言葉が同じ文に現れても混乱しない。
| パスの形 | 生成の時点 | 可能な例 |
|---|---|---|
| 固定パス | 事前レンダリング | /aboutをビルド時に事前生成 |
| 固定パス | リクエスト時のレンダリング | /dashboardを利用者のリクエストごとに生成 |
| 動的パス | 事前レンダリング | /posts/[slug]のページ一覧をビルド時に生成 |
| 動的パス | リクエスト時のレンダリング | /products/[id]をリクエストデータから生成 |
記事を読む: sass.studio.