generateStaticParamsでSSGの仕組みが見えてきた

前回の記事で、SSGはビルド時に静的HTMLを生成しておき、 アクセス時には事前に生成されていたHTMLを返すだけなので、 本番環境では爆速表示ができる。 逆にローカル環境ではその速さの恩恵が受けられない、ということを学びました。

では次に、Next.jsは何を見てビルド時にHTMLを生成しているのか。

この記事ではそれを深掘りしていきます。

きっかけ

このブログでは、一覧画面はアクセスのたびにNotion APIにアクセスして記事一覧を取得しています。 SSGを使っているのはブログの詳細画面、つまり記事のHTMLとタグ別記事一覧のみです。

（余談） 逆に言うと、トップ画面からは記事が見えているのにクリックすると404ページになる場合。 これは主がブログ公開後にリデプロイを失念しております、、ご了承ください😅 きっと数日後には見られるようになります笑

ただしブログ記事もタグ一覧も動的パスで、/posts/[slug]のように実装しています。 そう、動的に変化するパスなんです。 だとすると、Next.jsはどうやってあらかじめ生成するページを見分けているのでしょうか。

ここで登場するのが、generateStaticParamsという関数です。

React民からすると、 「誰やねん、君。長ったらしい名前だな。勝手に補完もされないし、覚えにくい、、」 なのですが、この人、SSGにおいてめちゃ大事な人でした。

具体的な実装

generateStaticParams は、このブログではこう実装しています。

export async function generateStaticParams() {
  // 一覧画面と同じ情報を取得
  const posts = await getPublishedPosts()
  // 取得できたpostsから、slugのみをピックアップして配列で返す
  return posts.map((post) => ({ slug: post.slug }))
}

/** 公開済み記事の詳細ページを生成する。 */
export default async function PostPage({ params }: PostPageProps) {
  const { slug } = await params
...

ここでもう一度再確認です。

generateStaticParams は、ビルド時にNext.jsから実行されます。

つまり、ここでgetPublishedPostsを呼び出して有効なslug情報を取得して初めて、 生成すべきslugの記事を認識できるわけです。

あとは返されたslugごとにPostPageが生成され、静的HTMLが出力される。 こんな流れになっています。

今回の学び

SSGはビルド時に静的HTMLを生成する。 どんなページのHTMLを生成すべきかは、generateStaticParams を通じて教えてあげる。

これは実感しないと理解が難しかっただろうなと感じました。 今回体験できてよかったです！