getStaticPaths
返り値
nextがGetStaticPathsという型を用意している
paths :: string[]
/posts/[postId].tsxのようなページがあるとき
事前にどのpostIdを静的ビルドするか、を決められる
getStaticPathsの返り値に配列として指定する
e.g. paths: [ { params: { id: '10' } }, { params: { id: '11' } }]
postIdが10,11のもののみをビルド時に静的ファイルを生成
例えば「最近公開されたpostを10件」を指定する
fallback :: boolean | 'blocking'
userがbuild時に生成していないpathへアクセスしたときの挙動を決める
false
404 pageに飛ばす
使いどころ
ページ数が少ない時に、有効なidは全てbuild時に生成できるぐらいの量
かつ、無効なidが来た場合は404に飛ばす、というのが楽に書ける、という感じ？
dynamic routingが少量な、普通のgetStaticPropsみたいなイメージかmrsekut.icon
true
実装にも依るけど普通はここでloadingを表示したりする
一度でも誰かがそのpathにアクセスすると、
client側では、
①不完全なHTMLページを返却する
データ取得を必要とする部分以外が描画された静的なページ
プリレンダリングされたページ
②データを取得する
③取得後、描画して、完成
server側では、
①cliend側と同様にJSを実行してデータの入ったHTML静的ファイルを生成
それ以降のそのpathへのアクセス時は、その静的ファイルを返すようになる
つまりpathsに新しくそのpathが追加されたような感じになる
blocking
fallback動作をblockする
pathsで指定されていないpathへ遷移した時、SSRを行ってから返却する
初回のみ。それ移行はtrueと同じ
「不完全なHTMLページ」を先に返却するのではなく、サーバーサイドで完全にレンダリングしてから返却する
「不完全なページ」の状態をユーザーに見せなくて済む
その代わり、体感の待ち時間が長い
client側ではJSを実行していない
ただ静的ファイルを受け取って返している
ビルド時にログの出力として、ビルド対象になったパスが表示される
code:log
├ /zeit/ms
├ /zeit/micro
├ /zeit/test-listen
この結果から、30個のpathについて事前に生成されたことがわかる
参考
わかりやすいmrsekut.icon
わかりやすいmrsekut.icon