Access search params prop via SegmentStore - #97220
Conversation
Moves the search params prop to be stored on the SegmentStore, like we did in a previous step for the vary params accumulator. This means we can now materialize a search params prop at any point during a server render, without having to traverse through the route tree. Eventually we'll use this to reify a Server Reference that represents the search params object. We'll also use the same strategy for pathname params. The searchParams object that a page receives is now created lazily on first access. No behavior change.
Failing test suitesCommit: 302d96b | About building and testing Next.js
Expand output● segment cache (search params) › stores prefetched data by its rewritten search params, not the original ones ● segment cache (search params) › handles rewrites to the same page but with different search params ● segment cache (search params) › handles rewrites to the same page but with no search params
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite
Expand output● segment cache (search params) › stores prefetched data by its rewritten search params, not the original ones ● segment cache (search params) › handles rewrites to the same page but with different search params ● segment cache (search params) › handles rewrites to the same page but with no search params
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite
Expand output● segment cache (search params) › stores prefetched data by its rewritten search params, not the original ones ● segment cache (search params) › handles rewrites to the same page but with different search params ● segment cache (search params) › handles rewrites to the same page but with no search params
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite
Expand output● app dir - basic › searchParams prop › server component › should have the correct search params on rewrite ● app dir - basic › searchParams prop › server component › should have the correct search params on middleware rewrite |
Stats from current PR🔴 2 regressions, 1 improvement
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
Build Cache
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (22 files)Files with changes:
View diffsapp-page-exp..ntime.dev.jsfailed to diffapp-page-exp..time.prod.jsfailed to diffapp-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsfailed to diffapp-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsDiff too large to display app-page.runtime.dev.jsfailed to diffapp-page.runtime.prod.jsfailed to diffapp-route-ex..ntime.dev.jsDiff too large to display app-route-ex..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route.runtime.dev.jsDiff too large to display app-route.ru..time.prod.jsDiff too large to display pages-api.ru..time.prod.jsDiff too large to display pages.runtime.prod.jsDiff too large to display use-cache-pr..ntime.dev.jsDiff too large to display use-cache-pr..ntime.dev.jsDiff too large to display use-cache-pr..ntime.dev.jsDiff too large to display use-cache-pr..ntime.dev.jsDiff too large to display 📎 Tarball URLCommit: 302d96b |
Moves the search params prop to be stored on the SegmentStore, like we did in a previous step for the vary params accumulator.
This means we can now materialize a search params prop at any point during a server render, without having to traverse through the route tree.
Eventually we'll use this to reify a Server Reference that represents the search params object. We'll also use the same strategy for pathname params.
The searchParams object that a page receives is now created lazily on first access.
No behavior change.