Ability to reset location/history state on second router instance startup? (module-federation related)

[hrmcdonald]

Challenge

We have a large module-federation based platform. We're big fans of Tanstack libraries and are providing a router syncing solution that enables child "micro-apps" to leverage Tanstack router within our platform easily by leveraging createMemoryHistory. We have a hook that taps into global platform events that sync router state between the parent platform and child micro-apps. We even have route preloading synced up this way where relevant (thanks to router.preloadRoute) which is awesome.

So far everything has gone great. The biggest challenge occurs when navigating back to a Tanstack router micro-app after it has already been loaded and navigated once before.

For whatever reason Tanstack router insists on reloading whatever route it was on last navigated to during that second initialization - cancelMatches() does nothing there, navigating to the new requested route is seemingly ignored, overriding the history object doesn't work either.

Non-ideal Solution

The only thing that would work is essentially forcing users hand us a factory for their router so we can initialize a new router instance each time. This should work fine but has some downsides - all router/loader caching gets thrown out the window when it doesn't have to.

Requested Solution

It'd be great if the router instance had a top-level method we could call to reset it's state. Maybe even just something to replace it's history instance? That way we could just provide it a new one of those with a new initialEntries array of the route it should be loading now.

Examples:

router.resetHistory({ initialEntries: [requestedInitialRoute] });

If this only makes sense for the memory router then maybe it could just be a method on that object?

router.history.reset?.({ initialEntries: [requestedInitialRoute] });

[hrmcdonald]

We were able to mostly handle this by updating some core router state before disposing of the child react app. It's certainly janky and might need to be adjusted with updates since we probably aren't supposed to be using commitLocation() like this.

This was done with the following:

// Mostly resets the router history
// This provides a new history instance, but does not alter existing state
router.update({
  ...router.options,
  history: createMemoryHistory(),
});

// Commit a false location so onEnter always refires
// This forces the router to consider the next initial navigation to even `/` as a new transition so that `onEnter` fires correctly if this "micro-app" is re-initialized.
router.commitLocation({
  href: '',
  pathname: '',
  search: {},
  searchStr: '',
  state: { __TSR_index: -100 }, // I just set this to an artbitray negative number that should never actually be a valid history entires index
  hash: '',
});