Support for nested routes?

[syrusakbary]

One of the big advantages about using React with React-Router is the nested routes.
It helps to abstract and modularize components in a way was impossible before.

In server-side everything renders at-once (usually), so there was not need of supporting nested-routes, and therefore none of the main frameworks support them (Express in js, Django/Flask in Python, Any PHP framework with the Symphony exception, Ruby on Rails). So, usually you end having one view/one route structure and a vitaminized context using Middleware (that in many cases could be easily replaced with nested-views pattern / except global middleware)

However when used in client-side it helps for making pages more dynamic and only load certain data for each component/route.
I'm willing to know if the decision of not having nested-routes here was premeditate and if this is the case, why.

Thanks!

[mridgway]

This is my own opinion on nested routes so don't take this any kind of decision. I'm open to seeing how nested routes could fit in to fluxible-router.

There are two benefits I see from having nested routes:

• Nested UI
• Less code to write routes
• Optimizing lookups (not done by react-router)

Let's first look at nested UI:

I see nested routes mapping one-to-one to nested UI components as very limiting. Ideally, you should be able to have any number of components nested for a given route rather than only the number of routes that are nested within each other.

With fluxible-router right now, we don't even have routes mapping to UI components as a first-class citizen. Instead, you can map any sort of metadata on the route object, including multiple components. You can achieve the same kind of nesting by having any number of keys on your route with different components: topLevelComponent, secondaryComponent, tertiaryComponent, etc. In this way, fluxible-router is much more flexible in my opinion.

If you wanted to execute separate actions for each of these components, you could map the route to an action that then reads statics from each of the matched components.

So if you assume that nesting UI isn't helped by having nested routes (as I believe), then let's look at the benefits of the other two:

Allowing nested routes allows you to write less code because you can nest objects and only write the folder path instead of the full path.

Nested routes also allow you to optimize the route matching logic because you don't have to iterate over the full list of routes, instead you can match nodes within a trie of sub-paths. It's important to note that last time I looked at react-router, it foregoes this optimization (even though ember uses it) in order to work around some of the restrictions that it imposes (more dynamic routing). It's important to note that optimizing this doesn't require that the developer use a nested structure for defining routes; this could be done instead as an automatic step during instantiation.

So given these two benefits, which I think are worthwhile, I feel like we shouldn't go as far as react-router in terms of supporting nested UIs and async data loading because

1. nested routes != nested UIs
2. async data loading should be done in Flux, not a router

Thanks for opening this issue. I think it's worth discussing. In the past, we didn't consider this a priority because we felt like we weren't trying to compete with react-router and it was out of the scope were aiming for; We just wanted a simple router that fit within the Flux flow better, but if there's a gap for adoption that we can fill we're all for it.

It would be good to compile a list of specific use cases that are possible in react-router but not fluxible-router and then see if there are suitable workarounds.

[syrusakbary]

Thanks for your detailed answer @mridgway.

You are completely right assuming that 2) async data loading should be done in Flux, not a router.
However, it's difficult for me to think in a case of a new route/url (could be nested or not) that doesn't imply a change in the UI.

The way we chose where this new component is placed/nested is completely our decision. But it have to be placed as children somewhere, of course. (As any react element).
The main assumption of Nested Routes implying Nested UI is not completely right.

Maybe the solution is create some syntactic sugar interface for having kind-of-nested routes with fluxible-router.
But coming from working with other server-side frameworks I can really see a great advantage for nested-routing.