Rerunning patchRoutesOnNavigation on a path

[dchenk]

So far I'm finding the new unstable_patchRoutesOnNavigation feature extremely useful! Thank you! However, it doesn't quite work for a common real-world scenario that I'm running into: suppose you have a route that requires authentication for any routes underneath it. Upon a user signing in, I'd like to imperatively re-run the patch function on the current path, since the set of routes accessible to the user changes.

For example, suppose I have a route at /dashboard/* which renders either a sign in form (when there's no user signed in), or the nested routes (/dashboard/widgets, /dashboard/etc, ...) with an <Outlet /> when there is a user. The server does not reveal that the routes under /dashboard/ even exist unless you're signed in.

But with patchRoutesOnNavigation, if an unauthenticated request comes to /dashboard/widgets, the /dashboard/* route is resolved as the route for the /dashboard/widgets page. The sign in form is displayed, and the user signs in. But then I can't mount the newly available routes. React Router caches the results of the first invocation of the unstable_patchRoutesOnNavigation function for the /dashboard/widgets path, so I'm unable to add the exact matching route /dashboard/widgets which would normally take precedence over the /dashboard/* route.

@brophdawg11

[brophdawg11]

Yeah I think it would be reasonable to remove the internal cache to allow this use case. Originally Remix was doing that to avoid making excessive discovery requests to the server - and it seemed like a common enough thing to move it into the router - but it's probably best left up to the app's implementation of patchRoutesOnNavigation if that is an optimization their app needs.

I would potentially recommend redirecting from a loader when not logged in to a "/login?redirectTo=..." route and then navigating them back to where they came from (redirectTo) after successful login - that keeps a nice separation of managing data/auth versus rendering UI. But even that approach suffers the same issue in the current state.

[dchenk]

Thank you for the reply. How do you feel about exposing an API that would allow us to imperatively re-run patchRoutesOnNavigation and update certain routes? I suppose this is two separate things—re-running the discovery, and then updating a route which, if I recall from my testing a few days ago, throws an error if you try to patch a route with an id that is already known.

[brophdawg11]

That actually already exists in a pseudo-private manner: router.patchRoutes. The methods on router are all marked "private" just because generally speaking you should use the react hooks instead (i.e., useNavigate instead of router.navigate). But I think we'll likely make some of them official public API in the future - especially ones like this that wouldn't necessarily have a react hook equivalent.

That would probably solve your problem now, if you patched in the new authed routes on login prior to navigating back to /dashboard/widgets

[brophdawg11]

FYI I'm removing the internal queue in #11977

[dchenk]

Thank you! @brophdawg11