[DO NOT MERGE] Deprecate nested routes with absolute paths

[taion]

From @ryanflorence on #3246 (comment):

Added the 3.0 milestone. We don't want to release this until we have features/improvements that depend on it, otherwise it's just annoying to our users. If we get those going we can move this to an earlier release.

@taion, mind enumerating the feature(s) that depend on this?

So I think at the end of it all, it looks like nothing strictly depends on this. It just makes a lot of things simpler, like relative link support, and lets us further optimize checking whether links are active.

So there's nothing strictly requiring this any more, but we should still do it sooner or later.

[ryanflorence]

This is useful for making:

1. our matching algorithm simpler
2. route configs clearer to humans
3. integrations that need to work with paths simpler (like named routes, relative routes, whatever else)

All previous UI + url combinations are still possible but with some route config finagling--that's really the only trade-off (and JSF*).

<Route path="inbox" component={Inbox}>
  <IndexRoute component={Dashboard}/>
  <Route path="/message/:id" component={Message}/>
</Route>

// becomes

<Route component={Inbox}>
  <Route path="inbox" component={Dashboard}/>
  <Route path="message/:id" component={Message}/>
</Route>

// or (could happen if other routes make it seem cleaner this way)

<Route path="inbox" component={Inbox}>
  <IndexRoute component={Dashboard}/>
</Route>
<Route component={Inbox}>
  <Route path="message/:id" component={Message}/>
</Route>

Worth it?

(*) JavaScript Fatigue

[bensmithett]

1. route configs clearer to humans

I find the opposite true.

In this example, I have to manually concat 3 strings in my head to understand what the URL looks like

<Route path="/" component={App}>
  <Route path="about" component={About} />
  <Route path="inbox" component={Inbox}>
    <Route path="messages/:id" component={Message} />
  </Route>
</Route>

Whereas if you use absolute paths exclusively (we do) it's way clearer, especially in a sufficiently large route config.

<Route path="/" component={App}>
  <Route path="/about" component={About} />
  <Route path="/inbox" component={Inbox}>
    <Route path="/inbox/messages/:id" component={Message} />
  </Route>
</Route>

Mixing absolute & relative feels weird, but I'd miss being able to go exclusively absolute.

[timdorr]

You can put a comment in there:

<Route path="/" component={App}>
  <Route path="about" component={About} />
  <Route path="inbox" component={Inbox}>
    <Route {/* path=/inbox/messages/:id */} path="messages/:id" component={Message} />
  </Route>
</Route>

That being said, it would be cool if there was some utility similar to rake routes in Rails to list out the full route tree.

[taion]

@bensmithett I had thought about that use case a bit, and I'm not totally sure what to do there. The case we're worried about is less what you're doing, and more something like:

<Route path="/inbox" component={Inbox}>
  <Route path="/not-inbox" component={SomethingElse} />
</Route>

IMO this is quite confusing.

[bensmithett]

@taion is that necessarily a bad thing? I didn't think component nesting necessarily needed to dictate URL structure (via docs)

<Route path="/inbox" component={Inbox}>
  <Route path="/inbox/settings" component={InboxSettings} />
  <Route path="/message/:id" component={Message} />
</Route>

@timdorr yeeeah, but self-documenting code > comments!

(feel free to point me at other discussions, totally jumping in from the sidelines here 😄)

[timdorr]

@bensmithett See #3172 for reference. I think the contributing team is all sold on this, so it's going to happen. Personally, I even think it's dangerous to support nested absolute routes, as it's more likely to lead to error-prone behavior, pain, and sadness for all involved.

[ryanflorence]

I'm not against them, I <3 that the urls and component nesting are not coupled, that was a big deal to me when I first wrote any of the router code. But, I'm okay to see them go too since you can still accomplish the same UI + url combos w/o them.

Regarding the "all of them are absolute", I've seen quite a few people who prefer to do it this way ... wonder what it would look like if we allowed absolute urls as long as they matched their parent perfectly.

My main concern with this PR is that the benefits aren't huge anymore (we thought some other stuff depended on this, but turns out it doesn't), and to the folks using absolute paths, us removing them is just irritating.

[bensmithett]

Though I'd be slightly :sadface: (it's a feature I like & get value from, haven't experienced any pain) if this PR shipped I'd survive. Trade-offs gonna trade-off 😄.

(Also ❤️ 🎁 🍺 core team for all your work!)

[ryanflorence]

@bensmithett mind cut/pasting that question into a new issue since it's not related, I can answer it over there.

[bensmithett]

@ryanflorence done #3320

[taion]

This PR is pending an update to not drop support for #3319 (comment).

There's one other benefit to dropping nested absolute &c. support – it's that we can make <Link> (isActive) faster. Without nested routes w/absolute paths that don't match their parents, pathname being a prefix of currentPathname becomes a necessary condition for a path to be active.

In other words, if we take out this feature, and we want to see if whether /foo is active, we can immediately say no whenever the current pathname doesn't start with /foo/ (and is not /foo). In cases where there are lots of links, likely most of them will fail the isActive check immediately on this prefix thing, which should speed things up quite a bit.

[ryanflorence]

So sounds like here's where we're at:

1. Stuff can get faster
2. Implementation can be simpler
3. Sync and Async route configs are no longer inconsistent (assuming we do Change how we handle index routes with nested components #3326 also)
4. People can still do super clear absolute paths as long as they match their parent route perfectly

[taion]

I'd say for (2), if we keep support for non-conflicting absolute paths, the bigger change is that things become simpler conceptually. The implementation ends up looking almost the same, it's just that we know that if a parent route doesn't match, then it's "cleaner" to say that child routes won't match either.

[taion]

I'm thinking that we should actually move the matching logic into the route classes entirely.

[agundermann]

As for the performance gains and simpler implementation, couldn't we also achieve this by transforming absolute routes during initialization, similar to how JSX is resolved?

[taion]

I don't think so... we actually do need to look at the parent routes. I don't know – it's maybe not such a big deal in practice.

[petersendidit]

Looks like there is an extra we in this comment.

[taion]

Not much point keeping this open. Need a better plan before it makes sense to merge this.