Update search params without re-rendering everything

[cristianoccazinsp]

What is the new or updated feature that you are suggesting?

After migrating from v5 to v6, I noticed some new unexpected re-renders.

In short, the app updates query-string parameters (e.g., selected object id in a table) so if the user reloads the browser, or copies the link, the state is preserved. In version 5, changing the query string values would not cause a re-render from the very first component. In v6, changing the query string (using navigate, or the new useQueryParams hook), will always cause a full re-render from .

Is there a way, or would it be possible to allow for path/query string manipulations without firing a re-render?

Why should this feature be included?

Use cases where query-string manipulation is done only to preserve state, but not to do any actual react state changes.

[kiliman]

Updating search params is considered navigation, so re-rendering seems appropriate. If you need to maintain state, then I suggest using location.hash, as that's considered local state, and should not trigger navigation.

[cristianoccazinsp]

Is there any way to perhaps update it without triggering the re render? With a private API or something. Re working everything to use hash routes is a major effort, not to mention hash params look really ugly.

[kiliman]

Have you looked into location.state? This allows you to store state per location without affecting the URL.

https://github.com/remix-run/history/blob/main/docs/api-reference.md#locationstate

[artygrand]

Are you talking about navigate(location, {state: {modal: id}}) ? It's still re-renders, even with unchanged location

[cristianoccazinsp]

The goal is to actually affect the URL, so let's say if the user refreshes the browser, the component can restore its state from w/e was stored in the URL. Similar idea to allow external links to point to a specific place in the app. I agree this could live in the hash portion of the URL as well, but it is just not friendly to the user or even sharing/bookmarking links.

[cristianoccazinsp]

Actually, updating the hash part of the location will also cause a router re render:

this.props.navigate(
      `${this.props.location.pathname}#${params.toString()}`,
      { replace: true }
    );

[orderedspinach]

Just curious, but would History API's pushState function help here? With that you can freely change your urls (as long as you don't modify the origin), and on page refresh, react-router will reload based on the contents of that url.
Here's a Stack Overflow post with more information: https://stackoverflow.com/a/3503206/19108226

[cristianoccazinsp]

I did try using the history API, and it works at fist glance. However, react-router ends up out of sync so any code attempting to read from location, queryParams, etc., would break. Not saying it's not possible, as such code could just be updated to read the query string parameters from the history/location API as well instead of react-router, but it's a really bad side effect.

[orderedspinach]

So, when you update the query params, you also want the relevant hooks (location, query params) to be updated as well? It seems to me like a re-render should then be expected because how else should that data be updated?
Also, what is the consequence of these re-renders? For example, is it merely a performance issue?

[cristianoccazinsp]

The re renders are considerably slow (compared to v5), and can't even be memoized / used with PureComponents.

Here's an example of what we have, maybe it helps with some other ideas (wall of text ahead).

1. A main component that renders all routes, left side navigation, top-side header, and the "inner" component the route will end up picking. Left/top side components are also within a route as they may change based on the current route.

2. The inner components usually consist of a table, and a detail section. Each time an item is selected in the table, the detail section renders. This is managed by component state/props and there's no global state. Further, each time an item is selected the id is also stored in the query string, so if the user reloads, they are taken right where they left (this is where it re renders). The component then reads the query string parameter on mount in order to set its default state and continue were it left over.

3. In the above situation, the query string is only used to load / store an id so the table selection survives both page reloads, and can also be navigated right into (e.g., from other pages by setting the query string parameter). Re renders are fine when we change the actual page path, but when only changing the query string id on item selection, the entire page will re render from the very top , will re compute all routes (slow), re render both left and top side navigation menus, re render the entire table, and re render the item details.

Of course, some components (e.g., tables) are more or less optimized to only re render if items changed, so it is not that bad (still usable without the debug console open). You could say, optimize all your components to only re render if location.pathname changed then, but this wasn't needed in v5, and it would be extremely verbose to basically re write every single component that may listen to any of the navigation props to always check if pathname changed.

[romgrk]

I have a similar use-case that I'd like fixed, but with the hashpart.

I have an SPA with react-router. In one of the pages, the user can copy links to certain parts of the page like you'd expect with anchors & links, e.g. example.com/page#subsection, where #subsection points to a part of the page.
But currently, there is no way to set the current page location (for feedback purposes) to #subsection without getting a full re-render of the page.

[theMosaad]

I used this custom hook from @kentcdodds’s personal site https://github.com/kentcdodds/kentcdodds.com/blob/main/app/routes/blog.tsx#L185 for a similar use case.

[andrewborstein]

Is this the hook you're referring to?

https://github.com/kentcdodds/kentcdodds.com/blob/main/app/utils/misc.tsx#L296-L323

[kylewhitaker]

This is an underrated workaround

[claresloggett]

I'm a little puzzled in that approach why he's calling window.history.replaceState(null, '', newUrl) rather than window.history.replaceState(window.history.state, '', newUrl). Wouldn't we ideally like to maintain the unchanged, react-friendly state?

[aburkowsky9]

does this not seem a bit antithetical to the benefit proposed by remix to bypass syncing state given hes using useState:

https://github.com/kentcdodds/kentcdodds.com/blob/9adf648601bc5b1e0167d61a184f92718ed4861e/app/routes/blog.tsx#L176
https://remix.run/docs/en/main/discussion/state-management#url-search-params

this essentially creates a multi source of truth issue

[aburkowsky9]

update - it very much does. warning to anyone who goes with this solution. You will have a fun time making sure the two are synced for all your edge cases... Its useful for some use cases, but this is definitely not a great long-term solution.

[cristianoccazinsp]

@theMosaad that is just like manually calling pushState , which will basically leave react router out of sync if anywhere else you access the query params?

[theMosaad]

@cristianoccazinsp as far as i remember, it only rerenders the component and, therefore, react router gives you the new search params when you use it inside that component.

[dcworldwide]

Same use case (keeping a table's search filters as URL parameters so that the URL can be shared/bookmarked).

Except I'm using the provided useSearchParams hook. The setter triggers a re-render. Re-render loses all table viewport/paging positioning. Not a great UX.

Note: Tried using setSearchParams option replace: true and the default (push history). Both trigger a re-render

[JesusTheHun]

Are maintainers willing to accept a PR that fixes this ?

Edit : to be more specific, only the components that uses the hook and deconstructed a property that changed would re-render.

const [searchParams] = useSearchParams(); // Re-render every time any search param changes
const [{ page }] = useSearchParams(); // Re-render only when `page` changes

[LemonyPie]

searchParams are an instance of URLSearchParams and cannot be destructured this way

[franky47]

How about an optional dependency array passed as an argument?

import { useSearchParams } from 'react-router'

// Existing API: re-render when any search param changes.
useSearchParams()

// Proposed API: subscribe to a set of search params.
// Only re-render when those change.
useSearchParams(['pageIndex', 'pageSize'])

[dziugas-liaudinskas]

I believe I'm encountering a similar issue (#10741) where updating search parameters doesn't get added to the router history. Consequently, when returning to the page for the first time, scroll restoration doesn't work. If anyone has found a solution for this, I would greatly appreciate any assistance.

[Sen-442b]

Any update on this?

[ghost]

I had a similar case, it was necessary for a URL to have a certain parameter, but at the same time that adding/changing this parameter does not cause a re-rendering and triggering useEffect, where one of the dependencies was to monitor the change of searchParams.

The way I've solved it is this:

/**
 * Handles layout changes. We manually update
 * the URL in the browser without calling the
 * rendering and network request, and `searchParams`
 * has this parameter, and takes it into account
 * when changing URL parameters elsewhere in the
 * component
 */
const onLayoutChange = (layout: 'table' | 'tile') => {
  searchParams.set('layout', layout)
  window.history.pushState({}, '', '?' + searchParams.toString())
  setLayout(layout)
}

The point here is this:

• searchParams.set('layout', layout) - we set the parameter so that searchParams knows about it and does not overwrite it if we use searchParams.set() elsewhere in the component
• window.history.pushState({}, '', '?' + searchParams.toString()) - updates the URL in the browser by means of the browser itself, this bypasses the entire React application and does not cause any rendering or triggering of any effects
• setLayout(layout) - this is for my own purposes, where I update the layout.

I also have an effect:

useEffect(() => {
   // ... network request if `searchParams` is changed
  }, [searchParams])

It doesn't work (it's a wanted effect) because we don't update the state:

const [searchParams, setSearchParams] = useSearchParams()

[Nisha1205092]

thanks a lot. This works for me.

[KerlosSoNy]

thanks this works well.

[billymosis]

Hi guys, for me I wrote this middleware like recursive function to ignore specific path of search params query.
Maybe this could help to prevent re-rendering.

function addRevalidateToChildren(routes: RouteObject[]): RouteObject[] {
  return routes.map(route => {
    const children = route.children
      ? addRevalidateToChildren(route.children)
      : undefined;
    return {
      ...route,
      children,
      shouldRevalidate: revalidateIgnore,
    } as RouteObject;
  });
}

export const revalidateIgnore: ShouldRevalidateFunction = args => {
  return !args.nextUrl.search.includes('search_keyword');
};


// Usage
export const ProtectedRoutes: RouteObject[] = addRevalidateToChildren([
  {
    element: (
      <Suspense fallback={<PageLoadingIndicator />}>
        <Outlet />
      </Suspense>
    ),
    errorElement: <ErrorPage />,
    children: [
      {
        path: '/',
        index: true,
      },
      {
        path: 'users',
        loader: ensureAuthenticated,
        children: UsersRoutes,
      },
    ],
  },
]);

[684efs3]

Use:

setSearchParams(params, {preventScrollReset: true}

[claresloggett]

We have the same use-case. We have an app which respects state settings supplied as query params, and we want to dynamically update the URL to reflect the state the user sets on the page, so that, for instance, the browser can be refreshed and will come back to the same state. In our case, the state includes which tab is currently selected, and a re-render of the full component tree would include re-rendering hidden tab contents.

A re-render of the full component tree doesn't break the state (as the URL is consistent with the page state) but, because the state is already consistent, the re-render is unnecessary and a significant performance issue. I think we can't fix this with memoization.

At the moment the only workaround I can see is to use window.history.replaceState() as suggested a couple of times above. Maybe that is actually the right approach, since I'm asserting that the React component state is already consistent with the URL parameters we're trying to set? It just feels like there should be a better way.

[alexbu92]

using window.history is probably going to lead to nasty bugs down the line as that makes react-router's history state go out of sync with the browser's history. That being said, there currently is no other solution, other than 1. putting a shouldRevalidate handler on all active pages that returns false when that specific search param gets changed/added/removed and 2. replacing all searchParam dependencies of useEffects with a memoized version of the specific param you want to listen to.

[nzlotrfan]

Hello, any plans to fix this? Currently this just leads to unnessecary rerenders of my page.

[barbalex]

This seems like a reason to use tanstack router. As that is url-state first, I expect it to not have this bug

[lilouartz]

This is the solution I ended up with for my use case:

const getHighlightedUids = () => {
  return window.location.hash?.split('#')?.[1]?.split(',') ?? [];
};

const useHighlight = (uid: string) => {
  const [highlighted, setHighlighted] = useState<boolean>(false);

  useEffect(() => {
    setHighlighted(getHighlightedUids().includes(uid));
  }, [uid]);

  return [
    highlighted,
    () =>
      setHighlighted((current) => {
        const nextHighlighted = !current;

        if (nextHighlighted) {
          const nextUids = getHighlightedUids();

          nextUids.push(uid);

          window.history.replaceState(
            null,
            '',
            window.location.pathname + '#' + nextUids.join(','),
          );
        } else {
          const nextUids = getHighlightedUids().filter(
            (currentUid) => currentUid !== uid,
          );

          window.history.replaceState(
            null,
            '',
            window.location.pathname + '#' + nextUids.join(','),
          );
        }

        return nextHighlighted;
      }),
  ] as const;
};

This approach means that you can instant UI updates.

You can try this by clicking any of the ingredients on this page: https://pillser.com/supplements/kal-multisaurus-mixed-berry-407#53,59

[ondrejsevcik]

Technically, this is expected behavior. When the search params change, the loaders re-run since they may be depending on those query params. And that causes re-render.

In our case, the fix was to cache data in loaders and memoize our React components in various places to avoid unnecessary re-renders.

This is most likely the appropriate fix you're looking for. Everything else proposed here is error prone.

[artygrand]

What about the upcoming react 19 with compiler cache? Will it magically fix everything?

[sergiodxa]

The compiler might avoid the component to re-render, but not the loader to re-run since that's outside React.

[wenerme]

Workaround

export namespace SearchParam {
  export const Composite = ({ children }: PropsWithChildren) => {
    const [store] = useState(() => {
      return createSearchParamStore();
    });
    return (
      <SearchParamStoreContext value={store}>
        {children}
        <SearchParamSidecar />
      </SearchParamStoreContext>
    );
  };

  export function useSearchParams(names?: string[]): [Record<string, string[] | string>, SetURLSearchParams] {
    const store = useSearchParamStore();
    const value = useStore(
      store,
      useShallow((s) => (names?.length ? pick(s.value, names) : s.value)),
    );
    return [
      value,
      useCallback((args) => {
        store.getState().updateRef(args);
      }, []),
    ];
  }

  export function useSearchParam(name: string): [string[] | string, SetURLSearchParams] {
    const store = useSearchParamStore();
    const value = useStore(
      store,
      useShallow((s) => s.value[name]),
    );
    return [
      value,
      useCallback((args) => {
        store.getState().updateRef(args);
      }, []),
    ];
  }
}

type SearchParamStoreState = {
  value: Record<string, string | string[]>;
  updateRef: SetURLSearchParams;
};
type SearchParamStore = ReturnType<typeof createSearchParamStore>;

function createSearchParamStore() {
  return createStore(
    mutative<SearchParamStoreState>(() => {
      return {
        value: {},
        updateRef: () => {
          // no op
        },
      };
    }),
  );
}

const SearchParamStoreContext = createContext<SearchParamStore | undefined>(undefined);

function useSearchParamStore() {
  const store = use(SearchParamStoreContext);
  if (!store) throw new Error('useSearchParamStore must be used within a SearchParamStoreProvider');
  return store;
}

const SearchParamSidecar = () => {
  const [params, set] = useSearchParams();
  const store = useSearchParamStore();
  useEffect(() => {
    const next = new URLSearchParams(params);
    store.setState((s) => {
      s.updateRef = set;
      let keys = Array.from(next.keys());
      for (let key of keys) {
        let val = next.getAll(key);
        if (!val.length) {
          continue;
        }
        let v = val.length === 1 ? val[0] : val;
        if (!shallowEqual(s.value[key], v)) {
          s.value[key] = v;
        }
      }
      // remove keys
      for (let key in s.value) {
        if (!next.has(key)) {
          delete s.value[key];
        }
      }
    });
  }, [params, set]);
  return null;
};

[franky47]

nuqs has this behaviour by default when used in React Router (and Remix).

This feature is called shallow routing (at least in Next.js), and can be configured in nuqs' useQueryState(s) hooks with the shallow option. By default, no loaders are called, state updates remain local to the browser (using the History API), but if you need to read those search params in loaders for SSR, you can opt-in to notifying the server by setting shallow: false on them, and this will use the React Router / Remix navigation APIs.

Some notes: the stock useSearchParams from React Router / Remix is indeed not reactive to shallow updates, so we provide one that is (useOptimisticSearchParams, which also reacts to nuqs' optimistic UI updates when updating the URL).

Another perk of this approach is that we can implement key isolation / fine grained subscriptions on shallow updates, to only re-render the search params that actually have changed (like TanStack Router does). This is currently experimental (and feedback is welcome), and only applies to shallow updates: using the React Router / Remix navigation APIs to do a network round-trip does cause every search param listening component to re-render, but this feels like an expected behaviour.

Example of two counters, one that acts only on the client (it is not needed server-side), and one that needs to go through the server as it's read in a loader, squared and returned to the page component:

import { Button } from '@workspace/ui/components/button'
import {
  createLoader,
  parseAsInteger,
  useQueryState,
  useQueryStates,
} from 'nuqs'
import type { Route } from './+types/albums'

const ssrSearchParams = {
  a: parseAsInteger.withDefault(0).withOptions({ shallow: false }),
}
const loadSearchParams = createLoader(ssrSearchParams)

export async function loader({ request }: Route.LoaderArgs) {
  const { a } = loadSearchParams(request)
  return {
    squared: a ** 2,
  }
}

export default function Page({ loaderData }: Route.ComponentProps) {
  return (
    <>
      <pre>Squared: {loaderData.squared}</pre>
      <ServerCounter />
      <ClientCounter />
    </>
  )
}

function ServerCounter() {
  const [{ a }, setSearchParams] = useQueryStates(ssrSearchParams)
  return (
    <Button onClick={() => setSearchParams((prev) => ({ a: prev.a + 1 }))}>
      Server-aware count: {a}
    </Button>
  )
}

function ClientCounter() {
  const [count, setCount] = useQueryState('b', parseAsInteger.withDefault(0))
  return (
    <Button onClick={() => setCount((prev) => prev + 1)}>
      Client-only count: {count}
    </Button>
  )
}

Screen.Recording.2025-03-07.at.12.22.13.mov

[wenerme]

But nuqs dose not support HashRouter 47ng/nuqs#810 , still has to use the workaround #9851 (comment)

[barbalex]

This works great when using useSearch after migrating to @tanstack/react-router. No more unwanted rendering, only when the search value changes 😄

[braginteractive]

Why not use: https://reactrouter.com/6.30.0/route/should-revalidate in this case?

Don't revalidate on certain URL params

[ngtrthinh169TPC]

How would you use should-revalidate in this case? I just can't wrap my head around this.

Should I put shouldRevalidate: () => false, to every route that has searchParams change? That's the way I think make the most sense, but it's really verbose and error-prone.

[claresloggett]

Someone did suggest shouldRevalidate above (in 2023, it's an old thread!): #9851 (comment)

I haven't had time to try it properly but it sounds like it might be a fix. @ngtrthinh169TPC I could be wrong but my understanding is that you'd have to put in logic to compare the old and new URLs and if the only change is to a searchParam that you want to ignore, return false.

[tveimo]

As a similar use case, google maps updates its query parameters when you move around in the map. It does this so that you can reload the page the map is on, and still come back to the exact spot you were before the reload.