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.
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".
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.
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.
^ helped me understand what changes are coming.
Awesome docs, BTW!
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.
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.
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™
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.
i didn't see it mentioned in the docs, but does the new version fix the awkward handling of scrolling and history?
This is how software improves. You are not forced to upgrade to the next version.
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.
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.
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?
Ex. If I want to lazy load a route vs something below the fold, I can use the same HOC for both.
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.
font-family: Monaco;
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.