Shared route components

[ViewableGravy]

My company has several pages where multiple components are rendered on a page. Each section has a sidebar item and clicking on the sidebar scrolls the user to that part of the page.

This is implemented by having all components render in a single route component, but when a particular sub-route is matched then we scroll to that component.

So for example, our /service/$section route might look something like

const RouteComponent = () => {
  return (
    <SidebarPage>
       <Overview active="/service/overview" />
       <Billing active="/service/billing" />
    </SidebarPage>
  )
}

When converting to Tanstack router, we figured we can keep this pattern but to keep type safety on the routes, instead of making the last param a dynamic path segment (and only having one route), we have a route for each section and each route just shares the same component. So our routes look like this instead:

export const OverviewRoute = createRoute({
    getParentRoute: () => ServiceRoute,
    path: 'overview',
    component: RouteComponent,
});

export const BillingRoute = createRoute({
    getParentRoute: () => ServiceRoute,
    path: 'billing',
    component: RouteComponent,
});

Great. This worked, until the somewhat recent changes to memoize routes based on what part of the route has changed. When this was implemented, it means that this shared component remounts when changing routes which then triggers any of our logic that executes when the component is first mounted. It seems like this is because a key props is passed to the route component and this changes which tells react it's a new component (and hence a re-render).

This is... not ideal, especially at this late stage in converting our application. Going back a couple of versions is an option, but if the "problem" is never going to get resolved then we obviously don't want to lock ourselves to this version of the router and I'm looking for options.

Main Questions:

1. Would it be possible to opt out of route of this route memoization strategy at different levels of the router? I'd imagine being able to pass an option to a route to disable it (and children route) memoization might solve our problem but I also understand this is likely an anti-pattern so I don't know if this is really an option.

2. Since I'm not sure if disabling memoization is really a good option (just happens to be in my case), is there potentially a way that I could work around this with the current features of the router? I know there is a "shouldReload" function on a route but I'm not sure if this will help me at all.

To be honest, I considered changing up the routing to use a route hash for each thing on the page... This makes the most sense, but unfortunately there is no built in type safety for route hashes that I can see. Would having something similar to search params be possible? At the moment there is parseSearch but if there could also be parseHash or something then this would make route hashes a viable option.

Thank you to anyone who has any ideas in advance.

[schiller-manuel]

we are working on the remounting issue.
as of https://github.com/TanStack/router/releases/tag/v1.46.7, the remounting is fixed, however the component renders twice instead of once, so we need to understand why that is.

[ViewableGravy]

Thank you for letting me know! I've just told my company we are moving to hash routes anyway since using full routes for the same page really doesn't make sense.

Is a parseHash function likely to be something that could be considered in the future? The more I think about it, the better the idea becomes.

[schiller-manuel]

did you have a look at createHashHistory?

[ViewableGravy]

I don't think that's quite the same thing, I'm meaning for route hashes rather than using hashes for the history object.

What I meant by a parseHash method would be a way to verify possible route hashes that can exist.

So for example, it might be something like this

createRoute({
  parseHash: z.union([
    z.literal("billing"), 
    z.literal("renew"), 
    z.literal("overview")
  ])
  parseSearch: z.object({ search1: z.string() })
})

And then have the hash property on the useLocation hook (and other ways of accessing the hash) be typed accordingly.

To be honest, I completely understand that this is not a priority at all since it's not really a feature many people would use, but I imagine it'd be a very similar pattern to whatever parseSearch is doing internally, except only allowing strings.

---- edit
Sorry for the confusion, I meant the validateSearch method, not parseSearch.