Shallow routing on Next.js 13's next/navigation

[AndreSilva1993]

Summary

Currently in Next.js 13 when adding / removing the search params, I always get a hard-reload. In Next.js 12, one could do something like router.push('/?counter=10', undefined, { shallow: true }) and not trigger a hard reload. However in the current version the following code always causes a hard-reload and all the components re-render even though it's the same page.

import { useRouter, usePathname } from 'next/navigation';

function Component() {
  const router = useRouter();
  const pathname = usePathname();

  useEffect(() => {
    router.replace(!selectedItem ? pathname : `${pathname}?item=${selectedItem.slug}`);
  }, [dependencies]);

How can one achieve the Next.js 12 shallow routing in the current version?

Additional information

No response

Example

No response

[fredericenard]

Hey,

you can achieve the same result by putting the parts you don't want to re-render into the layout file.

[AndreSilva1993]

Isn't there any other way though? I interpreted a layout to be a re-usable skeleton of sorts in which the pages work within, that could also be nested. Moving the page's logic to the layout seems counterintuitive?

Let's say one has page with a paginated datagrid. When the user decides to see a different page of the results - and we want to change the URL including the ?page=2 so that the user could bookmark it - it wouldn't make sense to move the datagrid component to the layout file to avoid re-renders right? One would simply expect to be able to change the URL and change the datagrid's dataset without hard-reloading the page since it's the same one.

[hedysnike]

GOD BLESS U

[evgeny-kirichuk]

Hey. I've just faced the same behavior.
I'm doing the search params update according to the documentation.

const params = new URLSearchParams(searchParams);
params.set('countryCode', newCode);
const newParams = params.toString();
router.push(`${pathname}?${newParams}`);

And it completely reloads the page and triggers the data fetching in my server component container.
Have you found a way to fix it?

[AndreSilva1993]

Not yet, I've been waiting for a response. I'm a bit reluctant in creating an issue on the GitHub repository as I don't know if this is technically an issue but eventually I might do it to garner some attention to this.

[tacomanator]

FYI, the code mentioned here and in the linked documentation currently has a type error (see #49245). Until that is fixed, you can convert to a string: URLSearchParams(searchParams.toString()). If in pages directory, searchParams may be undefined so adjust accordingly: URLSearchParams(searchParams?.toString()).

[benton-droplab]

Would also be nice to be able to change a dynamic route segment without triggering a reload.

For example if there is an overlay component we want to show or hide based on the dynamic route segment, we don't want to make this a route because then every time the route changes we need to wait for the page's markup to come from the server, despite having both the component and data already on the client. So an option to navigate between the dynamic segments without triggering a page reload would be nice. Unfortunatly the workaround is a catch-all route and a client-side router (in this case, Wouter).

[joacub]

Yesss that how should work we don’t need almost any time to do a hard request un same segments or matching segments

Another easy workaround is using the layout and outing there the parts you don’t want to unmount

[afewyards]

But the layout does not have access to the server searchParams, which you might need for applied filtering in your overview

[actraiser]

I have a similar problem with current routing behavior or rather the lack of shallow routing.

My use case: I display a forum divided into three components, which are a list of topics of a selected board, a comments-list for a selected topic and finally a post for the selected comment, therefore i have an url similar to

/board/[boardId]/topic/[topicId]/post/[postId]

Now, clicking on a topic item should reload the comments list but not re-render the topics list itself which would also change the location within the list to the top position again which is not desired. Clicking on a comment-link in the comment list should also not re-render the topics-list but only update the post component which the new data.

Right now, I must simulate the routing by pushing the new url after clicking on an item in either list to the windows.history object using onClick-handlers in all links. Then I evaluate the parameters by parsing that new url and finally I put those values into a context which the three components consume. Clearly a cumbersome and awkward workaround to only get the specific components updated where the relevant url parameter changed.

I also checked the latest introduced router features (parallel routing and intercepting) but I did not manage to apply either for my use case. If anyone have a different suggestion on how to handle that case, kindly let me know.

-act

[AndreSilva1993]

This was fixed in 13.3.5-canary.2 so I'll just close this discussion!

[rgwebcode]

This was fixed in 13.3.5-canary.2 so I'll just close this discussion!

Was this also fixed for dynamic route updates with router.push() or .replace(), instead of just changing the search parameters? I'm still seeing a full page reload instead of just the URL being updated.
On 13.4.1-canary.2

[actraiser]

I also require that the browser does not reload the page when changing dynamic route segments - this is still not working in the latest release? I need to update individual components decoupled from each other by checking dynamic url params and NOT query params.

Greets
-act

[Tomekmularczyk]

I'm using nextjs "next": "13.4.1", and whenever I update search params with router.push or router.replace it causes all the server component code rerun. Is it by design? What if want to fetch some initial data when page loads, but do not need to refetch them when I update search param?

[JMURv]

I am using 13.4.4 version of Next JS. Problem is still here and it is very.. painful

[arathjz]

Using 13.5.4 and experiencing the same issue :/

[Tomekmularczyk]

Hard reload does not happen anymore but still you cannot do shallow routing. If I change search param, all the server code is rerun and fetches data on the server again.

I created separate discussion but @AndreSilva1993 consider opening this one up again.

[AndreSilva1993]

Re-opened it!

[jonuchiha]

I was doing a migration from my pages folder to the new app folder and used shallow routing a lot to get the functionality I desired. Is there a reason shallow routing functionality does not exist in the new App folder with NextJS Router (next/navigation) anymore and can this functionality be added to it?

Until then I have managed to get a workaround to this problem by using history.replaceState() [MDN] which offers the same functionality that shallow used to offer. Hopefully, the next team can get that functionality back into next/navigation.

[JS-GitRepo]

The only issue with this approach is usePathname() does not acknowledge the changed URL 🫤

[hedysnike]

does the useSearchParams on the client side acknowledge it ??

heck with it, I could make separate page for that specific url and just update the clientside with useState

[franky47]

I have released next-usequerystate (since renamed nuqs) 1.8.0, which brings shallow support for query string updates, among other things.

It does so by using the web history API directly in shallow mode, and the Next.js router when in non-shallow mode. Everything plays nice with standard <Link> and imperative router navigation, and it supports both the pages and app routers.

There's a playground to try it out: https://nuqs.47ng.com

I wrote a blog post on how it works under the hood, there were a few interesting findings along the way in building it.

It's also used in the Vercel dashboard. 👀

[franky47]

@abhion the upcoming adapters feature (which should land in v2) will let you customise how nuqs integrates with other routers (or wrappers around stock ones).

If you feel like playing with bleeding edge stuff, here's the PR (feedback welcome!):
47ng/nuqs#644

[abhion]

@franky47 this should work with next-intl as this changes only the search params, right? It doesn't change the actual url. Am I understanding correctly?

[franky47]

I'm not familiar with next-intl, but I know there were some tricks needed in nuqs to support all combinations of:

• Next.js version (13.4+)
• Pages vs app router
• basePath usage
• Dynamic routes ([slug], [...slug] and [[...slug]])

Getting the right base path to apply the URL was not trivial, due to discrepancies between routers, configuration and versions of Next.js. I'm not sure how adding i18n in the mix changes things.

[abhion]

@franky47 what next-intl's function does is add the current locale to the url when I do router.push("/some-page") . this will result in localhost:3000/en/some-page instead of localhost:3000/some-page. Since nuqs only changes search params there should not be any conflict with next-intl's custom router function. Am I correct?

[franky47]

@abhion I did a quick test and nuqs (latest, 1.19.1) & next-intl seem to work fine together (source):

next-intl.mp4

[JUNIORCO]

Why was my comment marked off-topic when it offered a solution to this problem? If my comment is considered off topic then please mark all other topics that try to offer solutions as off topic as well.

[JUNIORCO]

Does it matter which package is used? I gave a solution that people would find valuable until Next.js decides to work on this.

[MielkeDaniel]

In the meanwhile, for anyone who simply wants to change the URL without any additional functionality and just for the sake of showing a different URL, keep in mind that you can always change the URL with the native browser history api like so:

window.history.pushState({}, '', newPath);

Hope this helps for some of you!
Since there are some complains - once again: This is a none REACTIVE solution. This is purely static.

[ianldgs]

Indeed, you do state that and it's clear. However, this discussion is about shallow routing, which is more than just updating the URL for visual purposes. Hence the downvotes, I assume.

Be careful with:

    // make a copy of original function to avoid complications
    const originalPushState = history.pushState;
    
    return () => {
      history.pushState = originalPushState; // restore the copy
    };

I'm not sure if that's 100% safe.

I think that if the hook is called on multiple places, the second hook will not have the original history.pushState, it will have a reference to the first modified function that was created (possible memory leak).
Then, if the first hook is unmounted while the second is still running, it will restore the original history.pushState, making your second call be forgotten, thus not receiving any more updates.

[MielkeDaniel]

@ianldgs Ok yeah I see where you´re coming from. Yet people like me still come to this post, that simply were looking for a way to simply update the URL, so why not help them? I sometimes don´t understand the SO or GH community, how they dislike so much stuff, when there was nothing wrong with it.
The topic (of changing the url without reloading) is still the same, it simply is not reactive - as I stated, making it a valid answer in my eyes.
Such stuff simply keeps people from helping in forums.
Same goes for this guy @JUNIORCO , who made a valid comment on the topic, preventing help for at least SOME people, but gets marked as off-topic.
People get the same kind of issues in 100 different ways. If you can at least help some of them, why not go for it?
Whatever I guess...

Still thanks for clarifying!

[anonkey]

A safe option could be

declare global {
  interface History {
    _pushState?: (data: any, unused: string, url?: string | URL | null) => void;
    _listeners?: ((url: string | URL | null | undefined) => void)[]
  }
}

export const usePushStateListener = (listener: (url: string | URL | null | undefined) => void) => {
  useEffect(() => {

   if (!history._listeners) {
     history._listeners = [];
   }   
   if (!history._pushState) {
    history._pushState = history.pushState;
    history.pushState = function (data, title, url) {
      history._pushState!.apply(history, [data, title, url]);
      history._listeners!.forEach(listener => listener(url));
    }
  }


    history._listeners!.push(listener);

    return () => {
      const index = history._listeners!.findIndex(list => list === listener);

      if (index !== -1) history._listeners!.splice(index, 1);
    }
  }, [listener]);
};

[peterchaula]

Not sure why this was downvoted. But it does solve the issue to some degree.

[doougui]

It solved my problem as well. Thanks man!

[nikasepiskveradze]

Is there solution for this problem?

[meAnurag]

Any updates on this issue ?

[SamStenner]

+1️⃣ on this issue, major blocker

[Emiliano-Bucci]

Voi di Vercel siete un po' scappati di casa, ne? @timneutkens @leerob

[colinclerk]

If #58335 lands in GA, using replaceState for shallow routing will not work. Will an alternative for shallow routing land before then?

edit: misread the pr

[timneutkens]

using replaceState for shallow routing will not work

It quite literally gives you exactly the same behavior as what shallow does in pages so I'm not sure what you're referring to.

shallow in pages would update the Next.js router but not fetch the server. This does the same.

[franky47]

I can confirm it still works (with or without the flag, as long as you maintain history.state), at least for shallow updates of searchParams.

See 47ng/nuqs#394

[colinclerk]

Struck my comment - sorry for my confusion. I thought the PR overrode history.pushState to match the behavior of router.push, I didn't notice that it doesn't refetch server.

[timneutkens]

Hey all, I've landed #58335 on canary which allows you to get pretty much the same behavior as shallow in pages where it keeps the internal route state up-to-date but doesn't trigger an external fetch to the server. The same plumbing was needed for the navigate event in the future so this is an early version that solves most "shallow routing" requirements too.

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

[mdp-alex]

@mgreenw I'm running into the same issue. Wrapping search params in a useDeferredValue seems to work. So like:

const searchParams = useSearchParams();
const deferredSearchParams = useDeferredValue(searchParams);

Then I'm using deferredSearchParams in the suspenseful query.

And you can check whether it's pending by comparing the deferred and non-deferred params.

const isPending = searchParams?.get("sort") !== deferredSearchParams?.get("sort");

I tried using startTransition at first, but observed the same thing you did. Now I'm not using startTransition at all.

[arackaf]

@timneutkens @leerob is getting this integrated with transitions on the roadmap??

[A7xSV]

This requires updating existing <Link /> tags to a button to be able to use shallow routing (with window.history.pushState) which means we lose the benefits a native <a /> offers like opening it in a new tab. Is shallow routing for <Link /> tags on the roadmap?

[kcrwfrd]

@A7xSV I think you can just render an <a> tag like this

<a
  href="/foo"
  onClick={(event) => {
    event.preventDefault()
    window.history.pushState(...)
  }}
/>
  Foobar
</a>

That's roughly how next/link itself works.

[A7xSV]

@A7xSV I think you can just render an <a> tag like this

<a

  href="/foo"

  onClick={(event) => {

    event.preventDefault()

    window.history.pushState(...)

  }}

/>

  Foobar

</a>

That's roughly how next/link itself works.

Thank you! That's what I was thinking I'll land on ultimately but perhaps a nice to have for the shallow prop that we used to have in the pages router

[sanneh2]

I also dont understand the implementation of searchparams for state when any state changes and transitions are lagged out to the max. The app router is such a cataclysmic disappointment in 8 of 10 cases that I seriously considering supporting alternatives.

[tacomanator]

I have successfully been using nuqs and next-intl together in production, since about the time nuqs came out in a pages router project, and a little more recently in an app router project. Both have been without any particular issue related to nuqs.

…

On Reiwa 6 Sep 23, Mon at 5:39 François Best ***@***.***> wrote: @abhion <https://github.com/abhion> I did a quick test and nuqs (latest, 1.19.1) & next-intl seem to work fine together (source <https://github.com/franky47/nuqs-next-intl>): https://github.com/user-attachments/assets/bf7d9708-378c-48c9-b235-aecabbba6dee — Reply to this email directly, view it on GitHub <#48110 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPSMVELCNCLXVH77527GLZX4TIHAVCNFSM6AAAAAAWW72FSKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANZSGAYTONQ> . You are receiving this because you commented.Message ID: <vercel/next. ***@***.***>