V4 routes are “inclusive” by default which means more than one can match and render at the same time. So what’s that all about? V3 routing rules were “exclusive” which meant that only one route would win. In the previous example, you may have noticed the exact prop. This is because in v4, wherever the component is written is where the sub-component will render to if the route matches. Here it is in v3: import to nest components. The example app has just two routes for a home page and a user’s page. Perhaps the best way to see how v4 is different is to write a simple two-page app in each version and compare. Sure, the router could be partitioned and organized into several files, but conceptually the router was a unit, and basically a glorified configuration file. View Demo A New API and A New Mental ModelĮarlier versions of React Router centralized the routing rules into one place, keeping them separate from layout components. If you’re the type that prefers jumping right to a working demo, here you go: ES2015 Arrow Functions and their “implicit returns”.React (Stateless) Functional Components.

Here are some JavaScript concepts you need to be familiar with for this article: It mostly has bug fixes and internal enhancements to make it more compatible with React 16. React Router 5 is now available which is backwards compatible with React Router 4.

I will cover the most common API concepts, but the real focus is on patterns and strategies that I’ve found to be successful. My intentions for this article aren’t to rehash the already well-written documentation for React Router 4. Once I gained a new mental model for it, I realized that this new direction is amazing! Also, at first, I was over-complicating the use of v4. React Router 4 allowed me to do everything I could do with v3, and more. Eventually, new patterns emerged that made sense to me and I became very happy with the router’s new direction. I would have to change how I thought about the relationship between the router and the layout components if I was going to be successful. My mental model for using React Router 3 wasn’t migrating well to v4. The struggle was not with the API, but more so the patterns and strategy for using it. Admittedly, it was a struggle the first day. But just as JSX itself overcame its critics (at least most of them), many came around to believe that a nested JSX router was a pretty cool idea. However, the use of nested JSX routes wasn’t accepted by everyone. In some ways, earlier versions of React Router resembled our traditional mental model of what an application router “should be” by placing all the routes rules in one place. It reminded me of the push-back the first version of React Router had for its progressive concepts. Considering community cohesiveness and being that React Router plays a huge role in so many React applications, I didn’t know how the community would accept the changes.Ī few months later, React Router 4 was released, and I could tell just from the Twitter buzz there was mixed feelings on the drastic re-write. The idea of these changes gave me anxiety. Since the router is such a big part of an application’s architecture, this would potentially change some patterns I’ve grown to love. “Let me show you our ideas React Router 4, it’s way different!” Truthfully, I didn’t understand the new direction and why it needed such big changes. It was exciting to meet someone who built a tool I liked so much, but I was shocked when he said. Michael is one of the principal authors of React Router along with Ryan Florence. I met Michael Jackson for the first time at React Rally 2016, soon after writing an article on React Router 3.

React router v4 and reactxp