-
Notifications
You must be signed in to change notification settings - Fork 27k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using force-dynamic
causes layout to re-render on any navigation
#57326
Comments
pull bot
pushed a commit
to MichaelDeBoey/next.js
that referenced
this issue
Nov 22, 2023
### What? When a layout segment forces dynamic rendering (such as with `force-dynamic` or `revalidate: 0`), navigating to sub-pages of that layout will attempt to re-render the layout, also resulting in side effects re-running. This means if your layout relies on a data fetch and you render the result of that data in the layout, it will unexpectedly change when navigating between sub-paths, as described in vercel#57326. As a separate issue (but caused by the same underlying mechanism), when using `searchParams` on a dynamic page, changes to those search params will be erroneously ignored when navigating, as described in vercel#57075 ### Why? As a performance optimization we generate static prefetch files for dynamic segments ([original PR](vercel#54403)). This makes it so that when prefetching is turned on, the prefetch can be served quickly from the edge without needing to invoke unnecessarily. We're able to eagerly serve things that can be safely prefetched. This is nice for cases where a path has a `loading.js` that we can eagerly render while waiting for the dynamic data to be loaded. This causes a problem with layouts that opt into dynamic rendering: when the page loads and a prefetch is kicked off for the sub-page, it'll load the static prefetch, which won't be generated with the same router state as the dynamically rendered page. This causes a mismatch between the two trees, and when navigating within the same segment, a refetch will be added to the router because it thinks that it's navigating to a new layout. This also causes issues for dynamic pages that use `searchParams`. The static prefetch will be generated without any knowledge of search params, and when the prefetch occurs, we still match to the prefetch generated without search params. This will make the router think that no change occurs, and the UI will not update to reflect the change. ### How? There's ongoing work by @acdlite to refactor the client router. Hopefully it will be easier to re-land this once that work is finished. For now, I've reverted the behavior as it doesn't seem to be worth the bugs it currently causes. I've also added tests so that when we do re-land this behavior, we can catch these subtleties. Fixes vercel#57326 Fixes vercel#57075 Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Link to the code that reproduces this issue
https://github.com/cjonesdoordash/nextjs-prefetch-issue/tree/force-dynamic-issue
To Reproduce
Current vs. Expected behavior
Layouts shouldn't re-render on navigation if they're under the same route segment even with forcing dynamic rendering.
Verify canary release
Provide environment information
Operating System: Platform: darwin Arch: x64 Version: Darwin Kernel Version 22.6.0: Fri Sep 15 13:39:52 PDT 2023; root:xnu-8796.141.3.700.8~1/RELEASE_X86_64 Binaries: Node: 18.17.0 npm: 9.6.7 Yarn: 1.22.5 pnpm: 6.23.6 Relevant Packages: next: 13.5.4-canary.10 eslint-config-next: N/A react: 18.2.0 react-dom: 18.2.0 typescript: 5.2.2 Next.js Config: output: N/A
Which area(s) are affected? (Select all that apply)
App Router
Additional context
This issue reproduces on 13.5.4-canary.10 and later and was 99% due to the following change: #56228 @ztanner
This is also most likely related to the following issue: #57075
The text was updated successfully, but these errors were encountered: