React Router: Declarative Routing for React | Hacker News Reader

React Router: Declarative Routing for React

reacttraining.com

87 pointstm3365 comments

The new API looks quite a bit like the API we've been running in React-Router-Component since 2014 (https://github.com/STRML/react-router-component).

Of course, RRC is not as battle-tested as React-Router; it's more of a "works for us" project I took over from @andreypopp as we had already committed to the router before React-Router became stable. And given the many backcompat-breaking changes to React-Router, it seems to have been a good idea.

React-Router does great work though; RRC doesn't even pretend to do React Native and the Environment selection we do have (pathname, pushstate, etc) isn't quite as nice. RRC also can't do some of the more interesting features, like Recursive Routes. All of the children of the router have to be `<Location>` objects.

Edit: React-Router's docs are awesome! Nice work @ryanflorence.

> backcompat-breaking changes to React-Router

We had breaking changes from 0.13 to 1.0.

Then complete BC from 1.0 to 2.0

That's two years, one breaking upgrade.

Don't confuse a libs "changing API" with "people use the development branch as stable".

Always felt kind of scummy that the same guys maintaining this library - complete with frequent breaking changes - are selling training around React for 1.8k a pop.

In other industries, we call this a "conflict of interest". "Same guys writing the building code for 2017 (featuring many changes from the 2015 code) are selling in-person workshops on the 2017 building code!" Take it out of the context of software and it immediately feels dirty.

I'm sorry I fail to understand how this is different than tutoring, say, a coach who's developed a training program selling DVDs and also getting paid for personal training on his own program.

This happens all the time, in many industries, where's the dirt?

Anyway, I'll take this chance to thank Ryan and Michael and Tim and Jimmy and others I forget for their hard work.

False analogy - RR is a de-facto standard in the web development community, hence my comparison to a building code.

No, RR is the de facto standard for the React community. And they're not doing training just on RR.

Claiming that because they made the most popular routing library for React it's shady to provide tutoring about it for profit is very much of a stretch in my book. Care to explain where exactly is the conflict of interest? Does that mean it's also shady to work as consultants? Where is the line drawn?

Do you really believe that noone is going to call them out if they started doing things deliberately to maximize profit (i.e. breaking changes without actual improvement, harder to understand than necessary APIs, etc)?

Ironically we typically spend less than 5% of a workshop talking about the router. So saying that we make breaking changes to sell tickets to our workshops is just naive. I can see how that's a gut reaction though, so no judgement on my end.

We had breaking changes from 0.13 -> 1.0. We had no breaking changes from 1.0 -> 2.0. That's 2 years with no breaking changes.

Our workshops have $899 early bird tickets.

Every software company I've ever worked for sells training and consulting for their software.

The docs are super good. I love the "embedded browser" that shows how it works.

Shameless self plug: our book [1] has a whole chapter on Routing in React with this new v4 router. After you've finished reading the docs, if you want a tutorial style walk-through of this router v4, we build a Spotify-type clone over the course of 75+ pages.

[1]: https://www.fullstackreact.com

I looked at your site. If you had video screencast that I could follow along. I would have paid for it.

We're going to have a (free) official video course up on the router site here within the next few weeks.

FWIW, while I haven't read it myself I've only heard great things about Fullstack React! Would recommend based on recommendations I've gotten.

Over the last month (or so), I've been reading and reviewing React books on my blog [1]. I liked Fullstack React, but there is one big thing that keeps me from recommending it: most of the examples still use the createClass from ES5. For learning React in 2017, I (just my opinion) expect the book to fully embrace ES6/7 in all the examples.

[1]: https://medium.com/@jmcunningham/

Yes, we're fixing that as we speak. It will be up to date shortly.

I am considering buying this for an engineer that works for me to get up to speed on React in the very near future. I only want to start him on ES6+ syntax though. How long do you think until it will be up-to-date?

The first chapter has already been updated to use ES6 class syntax, and we explain how it works there. We're converting the rest of the book to use ES6 classes (and removing createClass) over the next week or two.

You should remove your header of "up-to-date" on your marketing page until you get that fix in place.

Link to v4 branch: https://github.com/ReactTraining/react-router/tree/v4

^ helped me understand what changes are coming.

Could someone comment about how this compares with other projects like: https://github.com/react-community/react-navigation and https://github.com/facebook/react-native/blob/master/docs/Us... ?

Awesome docs, BTW!

react-navigation will supersede all existing navigator solutions in React Native core (Navigator/NavigationExperimental).

React Router v4 is building a react-native integration to show that it is capable of working on Native. It's centered around URLs so it's attempting to make Deep Linking into your application easier, as well potentially re-using the same navigation on the web.

That being said react-navigation can do both of those things as well and is fully supported by react-native core contributors.

Out of curiosity, why was the decision made to build a completely new router (react-navigation) vs collaborating on better native support to the existing react-router? (which is working towards that anyway)

Difference in opinions about what could be accomplished via react-router vs what native paradigms needed to be crafted.

Do you have a list of these native paradigms anywhere?

Difference is the API. React Router is a 100% declarative components, rather than configs and imperative actions.

From my perspective, React Navigation primarily differs from React Router in a few ways:

1) In RR, nav state is the URI. Because mobile nav state is complex, React Navigation treats URIs as actions to modify a more complex navigation state

2) RR uses React Components for navigation logic. In React Navigation, the isolated nav logic is statically available, (without rendering).

3) React Navigation is composable, so navigators can be configured to delegate navigation logic to child routers.

1) Not sure why navigating is "more complex on native". The platform the code runs on has nothing to do with the way the user interacts with the page. Complex navigation state is represented as one or many stacks of URIs.

2) In React Router you can have a statically available route config. This is React. Make an array then map it to render.

3) React Router is all components, so it composes exactly like the rest of your app. No new API to learn. It's Just React™

Navigating isn't more complex in native apps, and I didn't mean to imply that. But navigation state may be deeper than flat sets of URIs: it may be a tree.

For example: your app may have a stack of modal screens, and each of those screens may have tabs or a stack, and there may be another tab or stack navigation within each of those. In React Navigation, each node can be a router that manages its own navigation state.

I definitely like the way they decided to move in the latest version. I never was comfortable with the previous API -- it just didn't feel right, and it was kind of restrictive.

Neither were we >.< but we were learning React along with everybody else! You'll love this version.

In my experience, loving the new version is not an understatement. Great work, and thank you. It's been a pleasure to see React and the ecosystem around it mature.

Same here... It just shows how React isn't mature yet and also the scope for the future.

Will there be a way to access query / search parameters? The URL Parameters example could benefit from a such an addition, if it's already possible. Something showing how to get the genre out of `/netflix?genre=mystery` would be lovely.

I believe what you're looking for is `location.query` which can be accessed by children of your router (via `this.props.location.query`)

Thank you, I'll give that a try. The closest I saw in the current docs was via the `history` object, which I'd then have to provide to `<Router>`, which seemed sad. Using the props makes more sense! It looks like I want to use `withRouter` to get access to the location prop.

Actually it's`match.params.genre` with a route like this `<Route path="/:genre" component={Genre}/>` You can see it in these examples https://reacttraining.com/react-router/examples/url-params https://reacttraining.com/react-router/examples/ambiguous-ma...

I'm not sure I understand you. I'm asking for query parameters (`/foo?genre=mystery`), sometimes called search parameters, not URL parameters (`/foo/genre/mystery`).

I referenced the URL Parameters example in my original question and gave an example of what I meant, so I'm unsure how I could have communicated more clearly. That leads me to think that you are trying to answer my question and I'm not seeing it, but neither of the links you provided seem to show any URLs with a querystring at the end, after a `?`. Please let me know what I'm missing.

Sorry, your question was clear, I don't use search parameters in my app and got confused, I just check it and it's actually `location.search` that return a string `?genre=mystery'. The props passed to the component by `route` are not yet documented, this is what I gathered:

  "path": "/:genre",
  "computedMatch": 
    "path": "/:genre",
    "url": "/foo",
    "isExact": true,
    "params": 
      "genre": "foo"
  "length": 7,
  "action": "POP",
  "location":
    "pathname": "/foo",
    "search": "?genre=mystery",
    "hash": ""
  "match": 
    "path": "/:genre",
    "url": "/foo",
    "isExact": true,
    "params": 
      "genre": "foo"

you get location.search, which is just a string. We removed default query handling because it can be composed in with something like `RouteWithQuery` and `LinkWithQuery`. Lots of people didn't want the default serialization anyway. It's like 7 lines, we'll have an example of it you can copy/paste.

i like the power of the new API but i'm not sure i'm entirely sold on the declaration syntax. adjacent <Route/> tags which specify things that may appear in the same place depending on the route seems a bit strange conceptually to me. i'll have to play around with it on a real-world project to see how it feels in practice.

i didn't see it mentioned in the docs, but does the new version fix the awkward handling of scrolling and history?

browsers are handling that now https://majido.github.io/scroll-restoration-proposal/history...

also, not every app wants to do it the same way. Now that we're Just Components™ you can handle scrolling however you'd like.

I look forward to the next API revision. Churning your API frequently turns me off as a developer who would rather not be deprecated out the gate.

I look forward to the day where people can improve upon their project based on gained knowledge without passive aggressive comments about the lack of back compat.

This is how software improves. You are not forced to upgrade to the next version.

I look forward to the day when people can criticize a product for churning an API twice in one year without receiving the obligatory "if you don't like it, don't use it" cliché remark.

Improvement or not, to buy into a product that has churned twice in one year is a bad investment and for those who are lucky enough to not be caught in the middle - should be warned.

edit: I've used V4 and it's a vast improvement, but I stand by my remark.

0.13 -> 1.0 was breaking 1.0 -> 2.0 was fully BC

That was 2 years with only one breaking change.

2.0 -> 3.0 removed deprecated 1.0 API, fully BC with 2.0

The only churn is for people who don't stick to stable releases, and that's their own problem.

v2.0.0 released this on Feb 10, 2016

v3.0.0-alpha.1 released this on May 19, 2016

v3.0.0-alpha.3 released this on Aug 2, 201

v3.0.0-beta.1 released this on Sep 16, 2016

v4.0.0-0 released this on Sep 13, 2016

v3.0.0 released this on Oct 24, 2016

> ... and that's their own problem.

Hence deprecation right out the gate. V4 is much better, great work - but blaming users for API churn does not make me confident. Sure users could have used a stable release, but then upgrade twice? What confidence is there that it won't churn again?

I'm so confused. There are only two actual releases there: v2.0.0 and then 8 months later v3, where all that happened was v1 API was removed. If you only keep up with the stable releases your life has been simple with React Router.

Also, don't upgrade. v3 is going to maintained with bugfixes and whatever needs to happen to be compatible with new React releases indefinitely.

Been using V4 since they released alpha and it really is a great piece of software. Great work Michael and Ryan.

React Router V4 has been a pleasure to work with for me as well, and I've used it in a couple of projects that have some fairly complex routing.

This is a huge step forward in react routing. I'm still on v3, but very excited to switch. I love that I don't have to separate my thinking about routes vs normal components.

Ex. If I want to lazy load a route vs something below the fold, I can use the same HOC for both.

If you want to use React as the V in MVC you can always use a MVC router instead: https://github.com/rajeev-k/mvc-router

The website is broken on mobile - elements overlap and content is not visible.

Slightly off topic, but do you find that docs really need to be mobile friendly? I'd personally rather the developer focuses on the actual project and all those concerns rather than a perfect responsive docs page. Esp when assuming most of these docs are eventually translated into markdown on github which are then mobile friendly.

I tend to do exploration on my phone when I have downtime while being out and about. Mobile friendly docs are a sure way to keep my attention on your project if I stumble upon it during these times.

Of course, I do plenty of research from my desktop as well, so if it's a choice between getting a new release out on time or having a perfect mobile experience, I'd suggest library authors prefer getting timely releases out myself.

Absolutely, lets you study docs anywhere. Also looks low quality if a site breaks on mobile.

The markdown doc is here: https://github.com/ReactTraining/react-router/tree/v4/packag...

Yeah, I tend to research docs and libraries on-the-go, so working mobile documentation really helps me out.

only have time for so many things, v1 final release will have a site that works well on mobile too.

The code has 1 font with no backup:

        font-family: Monaco;

I don't have Monaco on Windows so it's using Times New Roman :\

I was going to complain about churn and such, but we've all heard the JavaScript framework fatigue story a thousand times.

I'll summarize it to this: don't expect a solid, stable, boring library to come out of someone's hobby project.

React itself bloomed under Facebook's stewardship, while all the other libraries in the ecosystem are bouncing all over the place without anything to keep them in place, especially after they lose their initial shine and geek points.

Kudos to the authors for their achievements. I don't recall you promising anything to anybody, so any code you put out contributes something to the world, even if you get bored and change the API from procedural to declarative and back three times a day.

Following stable releases we had one breaking API change in 2 years from 0.13 -> 1.0. 2.0 was fully BC, 3.0 removed 1.0 API 8 months after 2.0 was released. People shouldn't install beta/alpha like its stable and then complain to us about it.

I couldn't find it on the website, is there a detailed list of the changelog for this beta? Looks like some really great changes were made, but would love to see specifics.

We're working on an upgrade guide, but in short, it's a completely different library. Major difference is that routes are actual components that are actually rendered, where before they just had their props stripped and plugged into the routing machine. Now your routing is composed like the rest of your react app.

Will there be a way to prevent transitions when clicking on a link that isn't hooked into react router?

Reply on news.ycombinator.com