Nuqs slower than useStste
Hi, today I started replacing a useState controlling the state of a dialog with a useQueryState of nuqs and it feels way slower now. Any ideas why it is like that? Is that normal? It makes the app feel way slower and kinda makes me overthink if it really is a good idea to put the state in the URL.
6 Replies
This may be due to unnecessary page refreshes.
What framework are you using? I would sudgest to use some framework specific hook in the interaction with the URL params.
As far as I understand (i am 70% sure of this) you can push a new url with a page refresh or just push a new url. second option is what I think you should target.
Myself I have used this approach with no visible delays added. I used nextJs
^^ search params are essentially free, but how frameworks interact with it may not be
Next.js should have no issues with this use-case, I have even used search params just using replace for search bars and such with no visible delays
First thing, have in mind that in dev mode everything is slower.
I assume that changing the URL to append the searchParams is triggering the page to be re-rendered on the server when it’s not needed.
Nuqs should sync to the URL with a react state AFAIK, if it's triggering the page to re-render maybe it's not the library fault
I'm using next.js' app router together with the
NuqsAdapter from nuqs/adapters/next/app and the useQueryState from nuqs
It doesnt seem like the page is refreshing it just takes longer than just updating via useStateCan you share your code?
Nuqs doesn’t update the server by default (you opt-in with the
shallow: false option).
I’m currently working on running some optimisations for reducing re-renders, see https://github.com/47ng/nuqs/pull/849GitHub
perf: Optimise render counts by franky47 · Pull Request #849 · 47ng...
The optimal number of renders should be:
On mount: 1 (with the correct search params)
On update, with shallow: true (the default): 2 (one for the internal state, and one when the URL has updated)
...