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

[RobinNagpal]

I have url in the form /tidbits/view/${tidbitId}/${stepOrder}. and the folder src/app/tidbits/view/[...byteIdAndStep].

Its a stepper and when I click next, I want to increment the stepOder.

using router.push('/tidbits/view/${byteId}/${nextStepOrder}') reloads/remounts the page component, which calls all the network hooks again and creates a very glitchy experience.

Any way to fix it?

[jonuchiha]

Thanks @jonuchiha that works 👍 💯

No worries, glad it's worked for you!

[AaronMullan]

Oh man been banging my head against this one for a while. Thanks!

[BenMcD0nald]

replaceState() isn't ideal in some circumstances though.

For example I'm needing shallow routing to update the page URL as a user scrolls with an infinitescroll component. replaceState does work for the url change however Next doesn't acknowledge it meaning that if the user clicks on a post and then goes back it'll reload it as a new page instead of seeing it as the same page with just a different page param.

Currently if I use router.replace() it does keep everything from before (data/scroll position etc) but just triggers the page to fetch fresh data and rerender the components every time

Losing my nut a little bit with this issue and cant seem to find any acknowledgement of it from the devs and/or roadmap to resolve

[manghat]

Thank you @jonuchiha this works for now.

[hedysnike]

replace/push has nothing to do scroll you have to put {scroll: false for it}

but if replaceState() is changing the scroll position I guess it's a separate issue

[jviall]

which workaround are you referring to?

[sjoerdvanBommel]

Hey all! After struggling with this issue for a while, I figured out a workaround which works pretty well in my project, so I wanted to share it. I only needed to update search parameters, so that's what this solution focuses on, but I assume it can work for any URL updates.

Please let me know if there's any downsides on my approach that I'm not aware of :)

1. Trigger a replaceState event everytime the history.replaceState function gets called:

lib/shallow-route-workaround.ts:

'use client';

const origReplaceState = history.replaceState;

history.replaceState = function () {
  const rv = origReplaceState.apply(this, arguments as any);
  const event = new Event('replaceState');
  (event as any).arguments = arguments;
  window.dispatchEvent(event);
  return rv;
};

2. Import the file in your root layout.tsx:

import 'lib/shallow-route-workaround';

3. Use the following custom (TypeScript) hook to automatically update the search params when changing the state and listen to the replaceState event to update state made by other components:

use-search-param-state.ts:

import { useEffect, useState } from 'react';

type ReplaceStateEvent = Event & { arguments: Parameters<typeof history.replaceState> };

export function useSearchParamState<T extends string>(
  paramName: string
): [T | undefined, (newValue: T | undefined) => void] {
  // Get the initial value from the URL search parameter or use the provided initial value.
  const initialQueryParam =
    typeof window !== 'undefined'
      ? (new URLSearchParams(window.location.search).get(paramName) as T) ?? undefined
      : undefined;

  const [state, setState] = useState<T | undefined>(initialQueryParam);

  useEffect(() => {
    const replaceStateListener = (e: ReplaceStateEvent) => {
      const argUrl = e.arguments[2] as string | URL | undefined;
      if (!argUrl) return;
      const url = new URL(argUrl, window.location.origin);
      const searchParam = (url.searchParams.get(paramName) as T) ?? undefined;
      if (searchParam !== state) {
        setState(searchParam);
      }
    };

    window.addEventListener('replaceState', replaceStateListener as EventListener);

    return () => {
      window.removeEventListener('replaceState', replaceStateListener as EventListener);
    };
  }, [paramName, state]);

  // Function to update both state and URL search parameter without adding to history.
  const updateState = (newValue: T | undefined) => {
    setState(newValue);

    // Update the URL search parameter with the new value without modifying history.
    const searchParams = new URLSearchParams(window.location.search);
    if (newValue) {
      searchParams.set(paramName, newValue);
    } else {
      searchParams.delete(paramName);
    }
    const newUrl = `${window.location.pathname}?${searchParams.toString()}`;

    // Replace the current URL without adding to the browser history.
    window.history.replaceState(
      { ...window.history.state, as: newUrl.toString(), url: newUrl.toString() },
      '',
      newUrl
    );
  };

  return [state, updateState];
}

Now in your component, you can use the hook for your state, while it will also update the query parameter that you passed along :)

import { useSearchParamState } from 'hooks/search-params/use-search-param-state';

export const ExampleComponent = () => {
  // 'book' refers to the search parameter key here
  const [book, setBook] = useSearchParamState('book');

  return (
    <p>{book}</p>
  )
}

[sjoerdvanBommel]

That's great, will make it a lot easier for others :) I might give it a try myself.
To be honest, this was code I added while debugging another issue that was unrelated in the end. So this could probably be removed indeed :)

[resthedev]

@franky47

The library looks great. I was about to have to convert everything to React/global state because of the lack of shallow routing with the current useSearchParams in app directory NextJS.

Would you mind commenting in this thread once you've added support for shallow routing in your library? I'm sure many people in this thread, who are holding their breath waiting for official NextJS shallow routing support, would appreciate it a ton.

[franky47]

It's available in the latest beta, you can see the server-side-parsing example which showcases it:

https://github.com/47ng/next-usequerystate/tree/feat/v2/src/app/demos/server-side-parsing

The lib is also a Next.js app so the usual next dev lets you run the examples.

Link to beta docs:
https://github.com/47ng/next-usequerystate/tree/feat/v2#shallow

[franky47]

FYI: I have released next-usequerystate 1.8.0 with shallow query updates in both app and pages router.

Announcement at the root of this disscussion: #48110 (comment)

[resthedev]

@franky47 Bless your soul

[franky47]

I have released next-usequerystate 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://next-usequerystate.vercel.app/

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]

@Emiliano-Bucci Yes:

const [lat, setLat] = useQueryState('lat', parseAsFloat.withDefault(0))
const [lng, setLng] = useQueryState('lng', parseAsFloat.withDefault(0))

function setRandomCoordinates() {
  setLat(Math.random() * 180 - 90)
  setLng(Math.random() * 360 - 180)
}

This works because it defers URL updates until the next event loop tick, so you can queue updates before they are all applied in one go.

You can also use useQueryStates (plural), which takes an object to set multiple related queries at once:

const [{ lat, lng }, setCoordinates] = useQueryStates({
  lat: parseAsFloat,
  lng: parseAsFloat
})

function setRandomCoordinates() {
  setCoordinates({
    lat: Math.random() * 180 - 90,
    lng: Math.random() * 360 - 180
  })
}

Whichever API you use is up to you, the second one was introduced to help with batching, but it has a nice advantage of accepting a runtime-variable object, therefore allowing an arbitrary number of queries (without violating the rules of hooks).

[Emiliano-Bucci]

@franky47 Thank you very much, I will try that! :)

[JurajKavka]

Vercel should hire you now!

[HurSungYun]

you are my hero! Thank you for your great job.

[h0lme3]

@franky47 thanks for your work!!!

[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.

[arthureberledev]

You can listen to it with a custom hook:

import { useLayoutEffect } from "react";

export function usePushStateListener(
  callback: (url: string | URL | null | undefined) => void,
) {
  useLayoutEffect(() => {
    // make a copy of original function to avoid complications
    const originalPushState = history.pushState;

    history.pushState = function (data, title, url) {
      originalPushState.apply(history, [data, title, url]);
      callback(url);
    };

    return () => {
      history.pushState = originalPushState; // restore the copy
    };
  }, [callback]);
}

And use it in a component like:

const [updatedUrl, setUpdatedUrl] = useState("");

usePushStateListener((url) => setUpdatedUrl(url));

[MielkeDaniel]

@ianldgs well that´s why I explicitely stated "anyone who simply wants to change the URL without any additional functionality(!!!) and just for the sake of showing a different URL".
But I understand how you can misinterpret this.
I´ll edit the message, that this is a none reactive solution. It´s just for simply changing the URL without a reload.

[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]);
};

[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

[ianldgs]

@resthedev how come updating an unrelated url param, with a shallow update, makes your code re-fetch stuff? Maybe you have more things than needed in some useEffect dependency list?

[resthedev]

@resthedev how come updating an unrelated url param, with a shallow update, makes your code re-fetch stuff? Maybe you have more things than needed in some useEffect dependency list?

@ianldgs My use case is a bit niche, but it is as follows:

1. User is on the gallery page (let’s say mysite.com/gallery)
2. User applies some filters (sort by, order by, filters) so the URL is mysite.com/gallery?sortBy=price&orderBy=ASC
3. User clicks on an image
4. Modal pops up and ideally the URL in the browser should change to mysite.com/images/1 for example
   If the user reloads the page or someone opens mysite.com/images/1 directly, they should see a full page for the image (rather than in a modal)
5. When user closes modal, the URL shown in the browser should change back to mysite.com/gallery?sortBy=price&orderBy=ASC

The problem is that when the modal pops up and the URL in the browser is "changed" via window.history.pushState it also triggers all components using useSearchParams() to re-render (without the original search params like price and orderBy). So behind the modal, you see the UI re-render and re-fetch incorrectly.

I've tried NextJS's parallel/intercept routes but it's still not a smooth user experience. So for now, I've resolved to just manually patch the next.js package (using https://www.npmjs.com/package/patch-package to get my use case to work.

[melutovich]

@resthedev My opinion, I think you are asking from useSearchParams what might be good for you but not for most people. When in #4, you've changed the browser URL, the result is a removal of the search params. So before #4, you should be saving in your own state the values to restore to the search params and then in #5 to restore them. The "all components using useSearchParams" that is re-render should not be using useSearchParams but rather your on state storage of those params.

[mgreenw]

@timneutkens This doesn't seem to be integrating well with transitions when the call to window.history.pushState is wrapped with startTransition. router.push causes isPending to work properly, but window.history.pushState does not.

This is a primary use case when shallow routing. Any ideas? Thanks!

'use client';
 
import { useTransition } from "react";
import { useSearchParams } from 'next/navigation';
 
export default function SortProducts() {
  const [isPending, startTransition] = useTransition()
  const searchParams = useSearchParams();

  // This suspenseful query causes the component to suspend based on the value of `sort`
  const query = useSuspenseQuery({ sort: searchParams.sort });
 
  function updateSorting(sortOrder: string) {
    const params = new URLSearchParams(searchParams.toString());
    params.set('sort', sortOrder);
    startTransition(() => {
        window.history.pushState(null, '', `?${params.toString()}`);
    });
  }
 
  return (
    <>
      {/* This isn't working. I expect to see this pending state until the suspense boundary finishes */}
      {isPending && <span>Pending</span>} 
      <button onClick={() => updateSorting('asc')}>Sort Ascending</button>
      <button onClick={() => updateSorting('desc')}>Sort Descending</button>
    </>
  );
}

[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.