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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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'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:
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?
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.
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.
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.
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.
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.
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.