How to prevent unrelated rerenders?

[tordans]

I am adding Zustand and Nuqs to a new app.

When adding Zustand, I notice local rerenders of all components that consume the getter/setter.
When adding Nuqs, I notice global rerenders of all components, no matter if the consume the getter/setter.

I tried abstracting the Nuqs getter/setter into separate as recommended for Zustand in https://tkdodo.eu/blog/working-with-zustand but that does not help. #494 (comment) suggest that this is not needed ("The state updater function is also referentially stable across renders.") anyways.

But how can I get rid of the unrelated rerenders?

Video showing the rerenders (First no state, then Zustand added, then Nuqs added)

Update: The app is now open source at https://github.com/tordans/osmcha2
I switched to using Zustand for all state but the nuqs code is still there and it's just a replacement of ".zustand.ts" to ".nuqs.ts" for the imports.

output.mp4

[franky47]

I'd have to look deeper into your example on a big screen next week, but one thing that comes to mind regarding re-renders is the change of behaviour in useSearchParams since it became reactive of shallow URL updates.

The documentation mentions that the state updater function is referentially stable, which was relevant before, but now unfortunately any change to the URL will cause all useQueryState(s) to re-render.

This is not a great experience, I'd have to see if we can implement a scoped useSearchParam('key') into Next.js core.

Source: https://x.com/fortysevenfx/status/1796262844062986472

[tordans]

@franky47 thanks for confirming the issue. For bigger apps and especially when more state is put in the URL (which is the right way to do it in far more cases that is done today…), this feels like a big issue. So +1 for looking into a solution <3.

Thinking about it, that might also explain why we are having so many rerendering issues with atlas-app in recent weeks … we did update our Next JS version which might have pushed us to a version that always rerenders… (Demo link; but production feels snappy, luckily)

---

Follow up: Does this mean that react compiler (#566) will still help with preventing rerenders due to automatic memoization?

[roopakv]

this might be mis-understanding the issue, but if one were to use the native API, would that solve the issue?

https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#using-the-native-history-api

[roopakv]

never mind, i understand the issue better after reading #516. We have a fairly complicated app and re-rendering every component makes the app not feel as snappy (I'm sure we have some things to fix on our end too). Would be nice if there was a way to avoid this.

[franky47]

The best way to work around this is, like every React app, to move your state as down the tree as possible.

You can duplicate calls to the useQueryState(s) hook across components, their state will be kept in sync when updating search params.

[tordans]

A bit off topic but related: https://x.com/tkdodo/status/1818338443753136547 is talking about how React Router apparently has the same issue but Tanstack Query does not:

Another advantage of @tan_stack router is that you can subscribe to a subset of query parameters to avoid re-renders when unrelated params change. It makes the url a true state manager like e.g. zustand

[franky47]

Note: we're experimenting with "key isolation" that allows scoping re-renders only to the search params that did change, for supported frameworks, in #855 (unfortunately that doesn't include Next.js for which core changes would be necessary).

[pedro5g]

Hi, I don't know if this discussion is still open. But recently I had this problem with re-rendering and made a small implementation. So here goes my 2 cents .

Currently, shallow updates (shallow: true) still go through useRouter in Next.js, which causes unnecessary rerenders (see discussion #574
).

I propose separating two modes:

• Client-only mode (shallow: true) → handled internally by the library (via history.pushState/replaceState + pub/sub). No dependency on useRouter.

• Only components subscribed to the affected query param re-render.

• Prevents global rerenders while keeping the URL updated.

• Server mode (shallow: false) → keep using useRouter.push / replace, so Next.js revalidates on the server as usual.

This way:

• We get consistency with Next.js when needed.

• But we also get fine-grained control on the client where rerenders are the main issue.

I built a proof-of-concept implementing this idea, including a QueryManager, an internal queue system, and a rate limiter with Signals:

https://github.com/pedro5g/trigger.io/tree/main/hooks/query-state

[franky47]

Currently, shallow updates (shallow: true) still go through useRouter in Next.js

In the pages router only, the app router already uses the history API.

Your implementation looks very interesting! It would be nice to run it against the e2e test suite and see how it behaves 👀

[pedro5g]

Thanks for the quick reply!

I see, that makes total sense — in the App Router Next.js already uses the History API under the hood, so the issue is mostly visible in the Pages Router.

What I’m exploring with my implementation is a slightly different approach:

• On the client, when shallow: true, updates are applied directly via the History API + a pub/sub manager (without relying on useRouter).

• On the server, or when a full navigation is required, it falls back to router.push/replace.

This brings a few benefits:

• Granular control: developers can choose when to sync only the client state vs. when to involve the server.

• Less re-renders: components only re-render when the subscribed key changes (pub/sub style, similar to Zustand).

• Rate-limiting built-in: updates are scheduled and debounced with a signal-based queue to avoid race conditions.

I also read in #855 about the experiment with key isolation — scoping re-renders only to the search params that actually changed.
From what I understood, you mentioned that this isn’t currently possible in Next.js because it would require core changes.

In my approach, since I’m not relying on useRouter for shallow: true, but instead patching the History API directly with a pub/sub mechanism, I can get something very close to key isolation (each hook instance only re-renders when its own param changes).

I’d be happy to try running it against the e2e suite of nuqs to check compatibility!

[franky47]

I use a similar approach for the React Router & Remix implementation, where the History API is used with a cache layer (essentially a subscription, but without a central store, something I need to look into, see #1099) for shallow: true, but fallback to the router APIs for calling server loaders.

The pattern is kind of foreign and not really recommended in the "idiomatic React Router / Remix way", but it does yield good performance improvements (that folks in those communities had been asking for).

One drawback of this approach is that the stock APIs for those routers don't follow external updates to the History API, so if you were to have components that listen to the URL via the useRouter().query or useSearchParams/useLocation, they'd get out of sync with the URL.
In the React Router / Remix adapters, nuqs exposes a read-only useOptimisticSearchParams hook that is reactive to shallow updates (but uses unparsed string to serve as a replacement for the useSearchParams hook).

[pedro5g]

And @colsondonohue
if you're interested, I can also share the reduced version of my nuqs implementation so you can use and test it directly.

[colsondonohue]

would definitely be interested. does it maintain the same interface, etc.?

[pedro5g]

You can take a look here and test it
https://www.npmjs.com/package/@query-state/next

[colsondonohue]

cool, will take a look! would also love a jotai-style set hook, where I can use a typed setter without subscribing to changes

[pedro5g]

That's cool, Zustand and Jotai was my inspiration for state management. Plus, it has a refined auto type parse.