[Feature]: 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

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

[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