Replies: 1 comment 4 replies
-
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 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 ( |
Beta Was this translation helpful? Give feedback.
-
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 theunstable_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
Beta Was this translation helpful? Give feedback.
All reactions