Change how we handle index routes with nested components

[taion]

Currently we support this syntax:

<Route path="foo" component={A}>
  <Route component={B}>
    <Route component={C}>
      <IndexRoute component={D}>
    </Route>
  </Route>
</Route>

This is a little bit awkward and only works for sync child routes (i.e. it won't work if these child routes were declared via getChildRoutes).

I'd like to propose changing this API up a bit. A few options:

// Nest <IndexRoute> instead of pathless <Route>.
<Route path="foo" component={A}>
  <IndexRoute component={B}>
    <IndexRoute component={C}>
      <IndexRoute component={D}>
    </IndexRoute>
  </IndexRoute>
</IndexRoute>

// Add a nest() or compose() helper, or document it.
<Route path="foo" component={A}>
  <IndexRoute component={nest(B, C, D)} />
</Route>

// Add first-class support for array route components, with above semantics.
<Route path="foo" component={A}>
  <IndexRoute components={[B, C, D]} />
</Route>

If we take out nested routes with absolute path support, this would remove the only other inconsistency to my knowledge between the sync and async child route cases.

[ryanflorence]

Looks, good, lets hold off on any sort of utils to make the nesting easier.

If we take out nested routes with absolute path support, this would remove the only other inconsistency to my knowledge between the sync and async child route cases.

This is the nail in coffin for me and nested absolute routes.

[taion]

Should we add support for nesting <IndexRoute> like in the first example? We don't currently support it, but it should be easy to add.

[taion]

cc @danieljuhl, who added this feature in #2330.

[ryanflorence]

What does this become?

    <Router history={ history }>
      <Route path='/' component={ App }>
        <Route path='signup' component={ Signup } />
        <Route path='login' component={ Login } />
        <Route component={ ListPage }>
          <Route path='search' component={ Search } />
          <IndexRoute component={ Home } />
        </Route>
        <Route path='*' name='not-found' component={ NotFound } />
      </Route>
    </Router>

[taion]

Maybe:

<Router history={ history }>
  <Route path='/' component={ App }>
    <IndexRoute component={ ListPage }>
      <IndexRoute component={ Home } />
    </IndexRoute>
    <Route path='signup' component={ Signup } />
    <Route path='login' component={ Login } />
    <Route component={ ListPage }>
      <Route path='search' component={ Search } />
    </Route>
    <Route path='*' name='not-found' component={ NotFound } />
  </Route>
</Router>

There's some duplication, but maybe it's more clear?

This might be a bit of a harebrained idea on my part.

[agundermann]

Perhaps I misunderstand the intention, but is this really such a problem? Wouldn't it be easier to just use the route components for composition, instead of the router?

const A = (props) => (<B {...props}><C {...props}>{props.children}</C></B>)

[ryanflorence]

Yeah exactly, that's what I was thinking when I saw the nest thing.

[taion]

@taurose That's what I was thinking with nest() or compose(), but it's a little bit different when using async-props or react-router-relay or anything where the container wants to look at the route and inject stuff into the route components.

[ryanflorence]

I think @taurose code would still do that, no?

[taion]

Doesn't async-props work via a static loadProps method on the component? You couldn't necessarily merge two loadProps static methods without semantic knowledge.

[taion]

Given the tepid response here, and that this does legitimately make cases like #3326 (comment) harder, I'm going to close this out for now. The sync/async mismatch may be a non-issue once we resolve #3232 and put async child routes before the code split, anyway.