App Routerとは

https://nextjs.org/docs/app

Appルーターは、Reactの最新機能を使用してアプリケーションを構築するための新しいパラダイムです。すでにNext.jsに慣れ親しんでいる方であれば、App Routerが既存のファイルシステムベースのルーターであるPages Routerの自然な進化形であることがわかるでしょう。

• Next.jsの新しいRouter
  • 従来のRouterはPages Routerと呼称
  • フレームワークとしてはほとんど別物レベル
• Server first
• 積極的なキャッシュ
• Nesting Layout

App Routerのキャッシュ

App Routerにはいくつかのキャッシュ層が存在する

なぜRouter Cacheに着目したのか

App Routerの仕組みを研究してみようと思ったら、Router Cacheが複雑なことに気づいた

1. App Routerの遷移の仕組みに詳しくなりたかった
2. Next.js App Router 遷移の仕組みと実装
3. Next.js App Router 知られざるClient-side Cacheの仕様

App Routerの遷移を理解する

Router Cacheの話題に入る前に、App Routerの遷移を理解する必要がある

• App Routerでは、積極的にprefetchを行い、結果はcacheとして格納される
  • 内部的にはprefetchCacheと呼ばれているが、公にはRouter Cacheと呼ばれている
  • cacheと呼ばれてるが、遷移時に必ず必要となる
• 必要なcacheが見つからない場合、即座にfetchを行いRouter Cacheを更新する

Demo

https://next-router-cache-demo.vercel.app/

Navigationのポイント

• App Routerのrenderingにはstatic rendering/dynamic renderingの2つがあり、基本はstatic rendering
• 積極的にprefetchを行い、static rendering部分は早期にcacheされる
• dynamic rendering部分やprefetchが無効なページについては遷移時にfetchされる

cacheの内部的な分類

Router Cacheは内部的な分類を持っており、挙動がそれぞれ異なる

cacheのexpireが複雑

Router Cacheのexpireはprefetchprops・取得時間・利用時間によって分岐する

Cacheの状態ごとの挙動

• fresh, reusable: prefetch/fetchを再発行せず、cacheを再利用する
• stale: Dynamic Rendering部分だけ遷移時に再fetchを行う
• expired: prefetch/fetchを再発行する

Cacheのライフサイクルに影響する要素

• static rendering/dynamic rendering
• Linkコンポーネントのprefetch props
• 取得からの時間
• 最後にcacheが利用された時間

cacheのpurgeが複雑

cacheをpurgeする手段が複雑

• 以下の方法で全てのRouter Cacheのpurgeが可能
  • router.refresh()
  • Server Actions+revalidatePath/revalidateTag
  • Server Actions+cookies.set/cookies.delete
• 将来的にはServer Actions＋revalidatePath/revalidateTagは個別のcacheをpurgeできるようになりそう

https://github.com/vercel/next.js/discussions/54075

cacheがあるとIntercepting routesが機能しない

• intercepting routesとは
  • https://next-intercepting-routes-demo.vercel.app/
• Router CacheとIntercepting routesの組み合わせが設計からして相性が悪い
  • https://github.com/vercel/next.js/issues/52748
  • Intercepting routesはNext-Urlヘッダー（GETパラメータなどを省いたもの）に基づいて判定される
  • Router Cacheは現状URLパスをkeyにしているためNext-Urlが考慮されておらず、Intercepting routes時もcache hitしてしまう
  • Next-Urlをキーに含めるようにすると、これまでの何倍ものprefetchが行われてしまうので難しい問題

App Routerでよりシンプルになったものもある

• Server Components
  • より直感的なデータ取得とレンダリング
  • 一部ながらもtypeof window分岐とさよなら
• Nested Layout
  • URL仕様次第ではあるが、うまく使えば重複コードを減らせる
  • 遷移時に失われてたstateも保持できる
• Server Actions
  • RPC的な体験をライブラリなしで得られる

Pages Routerとの共存は暫定的な可能性

We are committed to supporting pages/ development, including bug fixes, improvements, and security patches, for multiple major versions moving forward.

https://nextjs.org/blog/next-13-4#is-the-pages-router-going-away

• 今後複数majorバージョンにおいてPages Routerのサポートは継続される
• その後のことは名言しておらず、Pages Routerがdeprecate・廃止される可能性はある
• 現状すでにサポートするとはいいつつ、新機能はApp Routerばかり
  • Pages Routerはバグも放置されがち？
• 現時点ではApp RouterはNext.jsの将来のメインストリームになる可能性はとても高い

App RouterとRouter Cache

• App RouterはNext.jsの今後の主軸になる可能性はとても高い
• App Router、特にRouter Cacheは複雑かつまだ不安定気味

より詳しい話はzennにも記事で書いてるのでよければ読んでください。

https://zenn.dev/akfm/