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.
8 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)
...
Hey y'all, if you want to give
[email protected] a try, it packs a few performance improvements. Planning to release it to GA before the weekend.@FleetAdmiralJakob 🗕 🗗 🗙 First thing that comes to my mind is that the query param updates in loop for some reason. Depending of how much callback enqueuing is going on in nuqs it might have become visible after adding
useQueryState.
Be sure, to check the results in React Dev Tools - record a minimal, noticeable example and then look for anything obvious. (e.g. 1000 renders for one click will almost definitely be a loop).
Looking at Nuqs source I cannot spot quickly anything that would obviously be connected to such behaviour.
Things like pagination, filters etc. are great in url params, so don't doubt that. I used this pattern for a long time (although not with nuxt), and I can guarantee this should not have any noticable performance impact.
And as someone already mentioned - be sure to check in built mode as well - in Dev everything is slower.