Support using useRoutes nested in <Routes> #9848
Replies: 2 comments
-
The closest I've gotten to ideal usage is doing option 1 and passing in an all-encompassing route whose element can be used for shared layout and children can be defined in another file. The only drawback here is that the routes still must be defined using // The main application routes — can be defined elsewhere in separate files
const AppRoutes = (
<>
<Route {...props}/>
<Route {...props}/>
{/* ...etc */}
</>
);
// layout or wrapper element(s) shared by all routes
const SharedLayoutWrapper = () => (
<LayoutWrapper>
<SomeSharedComponent/>
<Outlet/> {/* application routes will get rendered here */}
</LayoutWrapper>
);
export const App = () => (
<LoginLibraryComponent>
<Route path={''} element={<SharedLayoutWrapper/>} >
{AppRoutes}
</Route>
</LoginLibraryComponent>
) |
Beta Was this translation helpful? Give feedback.
-
I'm going to convert this to a discussion so it can go through our new Open Development process. Please upvote the new Proposal if you'd like to see this considered! |
Beta Was this translation helpful? Give feedback.
-
What is the new or updated feature that you are suggesting?
I want to be able to use the output of
useRoutes
nested as a child of the<Routes>
element.Context
I have a library that implements a shared login workflow that is used by multiple applications. The login screen routes are known in advance, and the main application route configuration is passed as children.
Essentially, in v5 I could do:
In v6, I'm stuck because I need to either:
<Routes>
component<Route>
elementsuseRoutes
or to wrap their routes in a shared layout-type component since all children of<Routes>
must be<Route>
<Routes>
and you run into the whole 'no routes matched' issue ([v6] [Bug]: "No routes matched" warning is too noisy #8095).<Routes>
container leading to an infinite loop of re-routing / re-rendering.<Routes>
can only have<Route>
children issue).Ideally, it would be nice if
<Routes>
could support items other than<Route>
as children, even if it's just being able to useuseRoutes
nested under a<Routes>
wrapper (that would open up the ability to use option 1 above, but with the flexibility to support dynamic routes defined either declaratively or using the hook):Why should this feature be included?
This would open up a lot more flexibility in terms of how routes can be defined.
The behavior was achievable in v5.
It seems like this would be a relatively common use case.
Beta Was this translation helpful? Give feedback.
All reactions