-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
Resets to initial state when there is Link with prefetch #388
Comments
Thanks for the reproduction. It looks like prefetch calls I'll see if that's a recent behaviour in the newest canaries, otherwise we might have to use a different strategy to differentiate external navigation from prefetches. |
I have yet to trace the full path taken from dispatching the A proof of this is using I'm not sure if the Next.js team would consider that a bug, but there may be other libraries interfacing with the history API that have a similar issue (eg: alternative routers). |
I can confirm this behaviour started to appear in 14.0.2-canary.7, specifically due to this PR: vercel/next.js#56497. |
This will pass up to 14.0.2-canary.7, which introduced a bug with prefetch resetting shallow query updates.
Note: 14.0.2 has been released with the PR that broke shallow URL updates when combined with prefetch links. |
@franky47 Could you tell me if you plan to maintain this repo for a long period of time? I plan to use it, but I don't want libraries that will "die" in a few months. Would really appreciate if you could give me some feedback about your plans with this repo :) Thanks! :) |
I'm actively using it across many production projects, it's not going anywhere. Ideally, I'd like to get some of the complexity pruned out by merging it into Next.js core (shallow routing in app router). That being said, it's also dependent on external factors, like a stable revenue stream, which is not the case at the moment. Sponsors are welcome to help with maintenance. |
Found the root cause of the issue. Let's follow the N whys: The main effect is, as described by @Arctomachine: Query updates get reset when hovering (or mounting) a prefetch Link.
The impacting PR did not change how the prefetch reducer behaves. It did not change the app router state when running in What changed however, is that the reducer state is now based on Promises. For each action, a new Promise is created. Those are referencially different, even if the state they resolve to is the same. The Solution: drop this Going to run this by the Next.js team, I'll update this comment with the PR number when it's out. Edit: vercel/next.js#58297 Notes: the sync (along with the whole Redux devtools code) was introduced in vercel/next.js#39866 Note: also keep an eye on these: |
@Arctomachine Could you please try the following combination, and let me know if you are still experiencing this issue?
|
It works now, tested on project where it first appeared - no problems so far. |
Thanks a lot for your feedback, I have released 1.12.0. Fingers crossed that PR on the Next.js repo lands on 12.0.3 🤞 |
## Description Between 14.0.2-canary.6 and 14.0.2-canary.7, a change was introduced in #56497 that turned the Redux store state into a Promise, rather than a synchronous state update. This caused the `sync` function -- used to send state updates to the Redux Devtools -- to be recreated on every dispatch, which in turn, by referential instability, caused the `HistoryUpdater` component to re-render and trigger a `history.replaceState` with no particular change, but with the internal `canonicalUrl`. When an app does a soft/shallow navigation by calling history methods directly (currently the only way to do shallow search params updates in the app router), these changes would have been overwritten by any prefetch (eg: hovering or mounting a Link), which is usually a no-op for the navigation state. This PR changes the `sync` function to take the state as an argument rather than as a closure. The whole app router state is also unwrapped only once, and fed to the HistoryUpdater. Changes to its contents made by reducers will cause the HistoryUpdater effect to re-run, triggering history updates and a call to the sync function. ## Context I maintain [`next-usequerystate`](https://github.com/47ng/next-usequerystate), which is used in the Vercel dashboard, and which is impacted by this change (see [#388](47ng/nuqs#388)). ## History @timneutkens introduced the `sync` function and the whole Redux devtools reducer in #39866, with the note: > a new hook useReducerWithReduxDevtools has been added, we'll probably want to put this behind a compile-time flag when the new router is marked stable but until then it's useful to have it enabled by default (only when you have Redux Devtools installed ofcourse). If a different direction is needed to keep sending `RENDER_SYNC` actions to Redux devtools, I'll be happy to rework this PR to move the `sync` function into the action queue. ## Changes - [x] Added e2e test. Requires a `start` mode as prefetch links are disabled in development. Test was verified to fail from next@>=12.0.2-canary.7 without the fix. Co-authored-by: Zack Tanner <[email protected]>
I'll publish |
Reproduction code: https://github.com/Arctomachine/usequerystate-bug
Only works in production (start) mode, not in dev
To "fix" it go to ./app/Wrapper.tsx, at line 33 change
prefetch={true}
toprefetch={false}
The text was updated successfully, but these errors were encountered: