Open taybenlor opened 3 years ago
There are few reasons to keep this router "flat", predictability(or discoverability) is one of them.
Recently we implemented nested routes for "flat" router using pregeneration for routing table:
slot
for one (or more) injected childrenTechnically speaking there is no difference between this and navigation example - every route record can hold as much information as needed, including all component to be rendered as "nested routes" and all their props as well.
Thanks! I think the issue I have with flat routing conceptually is that routing is a very "hierarchical" concept, and flat routing hides that hierarchy. I could potentially (as I think you've suggested) write my routes hierarchically and then use a function to flatten them out. It's not a great solution but I can understand if you feel that flat routing is a core idea of this router.
It's more about two different metal models forming the base requirements. Let's imagine you want to defer transition to a new page until "some" stuff is loaded (like in old non-SPA sites or NextJS):
useTranstion
+ Suspense
, call it a dayThe outcome is (almost) the same, but realizations are different. And it order to support this, and many other patterns, without not yet production-ready Concurrent Mode you might need flat routing.
And here we are. Well, will be
That makes sense! Thanks for taking the time to explain.
Hi!
This router looks great for render-as-you-fetch. But I noticed it doesn't appear to support nested routes?
This relay demo renders nested routing by rendering child routes as children. May be a possible implementation path.