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

[Ettorebigm]

Hi,

i think i face the same issue: in a dashboard there are buttons in the lateral drawer that modify the state of dashboard.jsx itself.
I'd like a way for the buttons to change the url (like button1 => /dashboard/activity1 ) and vice versa, i.e. for a specific url to change the state of the component.

How can i achieve this behaviour?

[Ettorebigm]

a little workaround can be found here https://www.reddit.com/r/react/comments/14h355i/how_to_use_react_router_correctly/

[rwilliams3088]

I have a similar problem. I don't mind the components that directly call useSearchParams being re-rendered when the search params change (that makes sense). However, I am attempting to pass the setSearchParams function down to child components - and I am finding that the function reference itself is changing everytime that a value is changed?! This seems erroneous.

const Child = (props) => {
   useEffect(() => {
      console.log(`setSearchParams ref changed?!`);
   }, [props.setSearchParams]);
   ...
   return (<Button onClick={() => setSearchParams(...)} >Click Me!</Button>);
}

const Parent = () => {
   const [searchParams, setSearchParams] = useSearchParams();
   ...
   return (<Child setSearchParams={setSearchParams} />);
}

EDIT: Reviewing the implementation of the useSearchParams function, this could be avoided by using an additional reference (searchParamsRef):

export function useSearchParams(
  defaultInit?: URLSearchParamsInit
): [URLSearchParams, SetURLSearchParams] {
  let defaultSearchParamsRef = React.useRef(createSearchParams(defaultInit));
  let hasSetSearchParamsRef = React.useRef(false);
  let searchParamsRef = React.useRef<URLSearchParams>(defaultSearchParamsRef.current);

  let location = useLocation();
  let searchParams = React.useMemo(() => {
    let searchParams = createSearchParams(location.search);

    if (!hasSetSearchParamsRef.current) {
      const keys = defaultSearchParamsRef.current.keys();
      let it = keys.next();
      while (!it.done) {
        let key = it.value;
        if (!searchParams.has(key)) {
          defaultSearchParamsRef.current.getAll(key).forEach((value) => {
            searchParams.append(key, value);
          });
        }
        it = keys.next();
      }
    }

    searchParamsRef.current = searchParams; 
    return searchParams;
  }, [location.search]);

  let navigate = useNavigate();
  let setSearchParams = React.useCallback<SetURLSearchParams>(
    (nextInit, navigateOpts) => {
      const newSearchParams = createSearchParams(
        typeof nextInit === "function" ? nextInit(searchParamsRef.current) : nextInit
      );
      hasSetSearchParamsRef.current = true;
      navigate("?" + newSearchParams, navigateOpts);
    },
    [navigate]
  );

  return [searchParams, setSearchParams];
};

I'm gonna try replacing the library's useSearchParams function with the above in my own code as a temporary work-around.

[rwilliams3088]

Created a PR with my bug fixes + unit tests: #10740

[0xMohamed]

what is the solution

[process0]

This is a similar issue as #7634 useSearchParams reads from the LocationContext, NavigationContext and RouteContext (through useNavigate). So when a change is made to any of these, useSearchParams is updated as well.

Without going as far as some of the solutions suggested in the other issue, I wonder if it would be possible to improve memoization and dependencies to reduce these re-renders.

@0xMohamed This is a known bug with no official fix #7634

[cliffordfajardo]

Somewhat related to this conversation is the { preventScrollReset: true } option you can pass to setSearchParams

setSearchParams(updatedSearchParams, { preventScrollReset: true })

Docs: https://reactrouter.com/en/main/hooks/use-search-params#usesearchparams

Somewhere in my code I was updating my URL search params & it looked like it was reloading the page, when actually it was just resetting the scroll position

unwanted-reloading.mp4

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

[kergian]

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.

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