Am I using nuqs with nextjs wrong?

[J4v4Scr1pt]

Nuqs version: 2.2.2

Don't get me wrong, I really really like nuqs and see the use of it! It's super awesome!

But I just implemented it a big project. Replacing the previous code using nextjs suggestion on using native history API to avoid unnecessary re-renders of RSC. Nuqs turned the code to be much cleaner and easier to work with.

However now we started to get a lot of server re-render which is not what I was expecting because of this in the docs.

I'm now considering removing it to go back to the previous implementation we had.

But I don't want to do that, so before I do it what am I missing here?
Is there some setting that I should turn off/on?

How is it working under the hood? Does it use the NextJs suggested way of working with the native history API as stated in docs with shallow?

Enlighten a stupid person as me please 😅

As an example, I have a simple dropdown with items that you can select, underneath is a list things based on the items Id.
When I select an item in the list I change the URL to reflect the new Id and trigger Tanstack to fetch the new data based on the items Id.
That's when I noticed the re-renders. I then removed Tanstack and all other code except the dropdown, but the re-renders still happens when I select the Id.

Code with the list to show, cleaned to show only the Id atm:

'use client';

import { useQueryState } from 'nuqs';

export function ListOfItems() {
	const [selectedId] = useQueryState('selectedId');
// tanstack trigger will happen here
return <div>{selectedId}</div>
}

The select:

'use client';

import { useQueryState } from 'nuqs';

export function Header({defaultSelectedId}:{defaultSelectedId:string}) {
	const [_, setSelectedId] = useQueryState('selectedId', {
		defaultValue: defaultSelectedId,
	});

	return (
	
			<Select
				size="sm"
				variant="bordered"
				radius="sm"
				color="default"
				onChange={(i) => setSelectedId(i.target.value)}
				disallowEmptySelection>
				{(item) => (
					<SelectItem key={item.Id} value={item.Name}>
						{item.Name}
					</SelectItem>
				)}
			</Select>
	
	);
}

[franky47]

However now we started to get a lot of server re-render which is not what I was expecting because of thisin the docs.

Are you sure your server-rerenders are coming from nuqs? Because as you said, and as it is, the default internal behaviour is to use the History API as recommended by Next.js for client-only updates of the URL.

This will cause re-renders on the client (at least two as the URL udpate is asynchronous, so one for the optimistic state update and one when the URL finishes updating to get back in sync), but it should not trigger any re-renders on the server on its own, unless you opt-in to do so with shallow: false.

[J4v4Scr1pt]

Thanks for all the fast response!
That's true what you say about react19. and yes only app router. But if it's just a regular Context provider then AI is lying.. 😄.
I will keep testing and get back again.

[franky47]

Yeah you might want to not trust AI on a piece of code that is less than a month old 🙃

https://github.com/47ng/nuqs/blob/next/packages/nuqs/src/adapters/next/impl.app.ts

[J4v4Scr1pt]

hehe I try to not trust AI as much as possible.. 😅.

But I do see that it's using the router to do the changes. Could this affect the re-render?
Have you considered using only the native window object as they suggest in the docs?
Not to replace router but rather have an setting on the options, something like "useNative" or similar?

I saw tough when I tested with window.history the useQueryState first got the previous value as a change before it got the correct new value.

Sorry if sound stupid or something I just brainstorming here. Nuqs is superb lib, like it a lot! 💪

[J4v4Scr1pt]

We can close this.

I found the issue it has nothing to do with neither Tanstack or nuqs... just my stupid *ss.. 😭.

In the docs for NextJs it does not say anything about you cant use ServerActions to fetch data. Even some youtubers have suggested doing this.

But I know better now, after I converted all my GET serverActions to be route-handlers all is good.

Thanks again for all your awesome responses!

[franky47]

Good to know, though this might change soon, as server actions were renamed to server functions in the React docs, so I guess the React core team has plans for them to be more than just POST mutations in the future, and finally erase the API routes paradigm.

[J4v4Scr1pt]

Let's hope so, because "serverActions" are so neat to write 😄