Bring back <Route name>

[mjackson]

There has been a lot of discussion about this already in #1514 and #1791.

We removed <Route name> in 1.0 for a few important reasons:

• Dynamically loading route config (i.e. getChildRoutes) means that we may not actually be able to build real URLs for <Link>s whose route config has not yet loaded
• We believe that using real URL paths in <Link to> doesn't take any extra time–you have to look up the route path or the name, which are usually pretty reflective of each other
• You don't have to know the parameter names to create links now
• We want to encourage users to NOT change their URLs–use a <Redirect> instead

Given the above reasons, it hardly seems worth it to bring back <Route name> as an API that we prescribe for everyone. However, some users believe that <Route name> can still be useful to specify a name for a route that can be used during development.

If we did bring it back, it probably work something like this:

// We can build up this map dynamically from your route config
const RouteNames = {
  home: '/path/to/home'
}

class NamedLink extends React.Component {
  render() {
    return (
      <Link to={RouteNames[this.props.name]} />
    )
  }
}

Please, please refrain from "+1" comments here and keep the discussion to the possible benefits/drawbacks to adding this feature back in. Thanks :)

[th0r]

They're back.

Incredible work, man!

[mwhite]

I was excited to see named routes in core mentioned in the roadmap of @taion's fork blog post, if I remember correctly. Is that still intended?

[everdimension]

@mwhite what don't you like about the post above? https://github.com/reactjs/react-router/issues/1840#issuecomment-206114104

[taion]

@mwhite I don't think we plan on adding them to core. I expect that the named route support will live in an extension for the time being.

[mwhite]

Allow me to quote from this excellent piece:

Though we allow modules to grow very large, sometimes it becomes apparent that a complex module can be simplified if broken up into ‘submodules’. In other cases, a group of modules may be usefully presented to the rest of the system through the public interface of a single ‘meta-module’. [emphasis added]

And -- gasp -- it's possible for the same package to contain both the core submodule and a meta-module that exposes a user-friendly interface through some combination of wrappers, multiple supported calling styles, and overridable default extensions.

Ergonomics are important. <Link to='widget' params={{widgetId: 'foo'}} /> offers readability advantages over <Link to={{name: 'widget', params: {widgetId: 'foo'}}>, especially if params is large, and possibly also higher-order programming advantages.

Users shouldn't have to import an external package to get named routes, because that's one more package to worry about and whether the extension API changes.

[taion]

That's certainly an option we're considering.

However, upstream React does use the "addon package" pattern quite extensively. See https://www.npmjs.com/package/react-addons-css-transition-group and https://www.npmjs.com/package/react-addons-shallow-compare most notably.

We agree that this is a feature that many users will want – otherwise I wouldn't have taken the time to code it up in the first place (as I don't use it) – and that is a factor we will consider, but I don't think there's anything wrong with the "addon package" model.

That also brings up a separate point – I wrote it to demonstrate that it was possible, but I don't use named routes, and I'm not sure any of the other project collaborators do as well. While there's not much code that can break, and I sort of care as a point of pride, it might be best for this feature to be maintained by someone who actually uses it.

[alvelig]

@taion If you don't use named routes, what is the best way to archive paths reusage. I mean if I want to type paths in one place and use corresponding variables in places where I need it? Is https://www.npmjs.com/package/use-named-routes the best way to archive it or is there another pattern?

Kind of:

const myRoutePath = "/here/we/go";

<Route path="/here" ... >
  <Route path="we" ...>
    <Route path="go" ... />
  </Route>
</Route>

<Link to="myRoutePath" >MY ROUTE PATH</Link>

[iErik]

Every single major SPA Router has this feature, the React community itself has been insisting for years now that it is an important feature, who had the idea that Named Routes is an disposable feature? At this point, the only drawback of using React is having to use React Router, a routing library that doesn't even support named routes.

[rande]

@iErik you might be disagree with this choice (I am too) however, there is a way to express opinion... also nothing force you to use this code ... also nothing force you to write a small helper fonction to generate routes.

[timdorr]

You can build this with something like the Route Config example from the docs: https://reacttraining.com/react-router/examples/route-config It no longer has to be baked into the core, just wrap some components with a dash of magic and voilà, you've got named routes.

Something like that would make a great addon package for 4.0. I'd definitely be interested in having that live alongside react-router-dom, react-router-native, and some other stuff that's going to live here in the near future. We're looking to build a whole ecosystem of addon packages to the simple core of react-router. No more batteries included, but the batteries will be available nearby :smile:

If anyone wants to champion an effort on that, please submit a PR and we can get the ball moving.

[ryanflorence]

Implementing a static route config and named routes on top of this project at this point is like a 20 line ordeal. 😂 If we baked it in we couldn't do recursive, dynamic routing.

SCREW US FOR GIVING YOU A MORE POWERFUL ABSTRACTION