{"id":257428,"date":"2017-08-07T04:53:19","date_gmt":"2017-08-07T11:53:19","guid":{"rendered":"http:\/\/css-tricks.com\/?p=257428"},"modified":"2019-03-28T08:47:57","modified_gmt":"2019-03-28T15:47:57","slug":"react-router-4","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/react-router-4\/","title":{"rendered":"All About React Router 4"},"content":{"rendered":"<p>I met <a href=\"https:\/\/twitter.com\/mjackson\" rel=\"noopener\">Michael Jackson<\/a> for the first time at React Rally 2016, soon after writing <a href=\"https:\/\/css-tricks.com\/learning-react-router\/\">an article on React Router 3<\/a>. Michael is one of the principal authors of React Router along with <a href=\"https:\/\/twitter.com\/ryanflorence\" rel=\"noopener\">Ryan Florence<\/a>. It was exciting to meet someone who built a tool I liked so much, but I was shocked when he said. &#8220;Let me show you our ideas React Router 4, it&#8217;s <em>way<\/em> different!&#8221; Truthfully, I didn&#8217;t understand the new direction and why it needed such big changes. Since the router is such a big part of an application&#8217;s architecture, this would potentially change some patterns I&#8217;ve grown to love. The idea of these changes gave me anxiety. Considering community cohesiveness and being that React Router plays a huge role in so many React applications, I didn&#8217;t know how the community would accept the changes.<\/p>\n<p>A few months later, <a href=\"https:\/\/reacttraining.com\/react-router\/\" rel=\"noopener\">React Router 4<\/a> was released, and I could tell just from the Twitter buzz there was mixed feelings on the drastic re-write. It reminded me of the push-back the first version of React Router had for its progressive concepts. In some ways, earlier versions of React Router resembled our traditional mental model of what an application router &#8220;should be&#8221; by placing all the routes rules in one place. However, the use of nested JSX routes wasn&#8217;t accepted by everyone. 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. <\/p>\n<p>So, I learned React Router 4. Admittedly, it was a struggle the first day. The struggle was not with the API, but more so the patterns and strategy for using it. My mental model for using React Router 3 wasn&#8217;t migrating well to v4. 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. Eventually, new patterns emerged that made sense to me and I became very happy with the router&#8217;s new direction. React Router 4 allowed me to do everything I could do with v3, and more. Also, at first, I was over-complicating the use of v4. Once I gained a new mental model for it, I realized that this new direction is amazing!<\/p>\n<p>My intentions for this article aren&#8217;t to rehash the <a href=\"https:\/\/reacttraining.com\/react-router\/\" rel=\"noopener\">already well-written documentation<\/a> for React Router 4. I will cover the most common API concepts, but the real focus is on patterns and strategies that I&#8217;ve found to be successful. <\/p>\n<p class=\"explanation\">React Router 5 is now available which is backwards compatible with React Router 4. It mostly has <a href=\"https:\/\/reacttraining.com\/blog\/react-router-v5\/\" rel=\"noopener\">bug fixes and internal enhancements<\/a> to make it more compatible with React 16.<\/p>\n<p>Here are some JavaScript concepts you need to be familiar with for this article:<\/p>\n<ul>\n<li>React <a href=\"https:\/\/facebook.github.io\/react\/docs\/components-and-props.html\" rel=\"noopener\">(Stateless) Functional Components<\/a><\/li>\n<li>ES2015 <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Reference\/Functions\/Arrow_functions\" rel=\"noopener\">Arrow Functions<\/a> and their &#8220;implicit returns&#8221;<\/li>\n<li>ES2015 <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Reference\/Operators\/Destructuring_assignment\" rel=\"noopener\">Destructuring<\/a><\/li>\n<li>ES2015 <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Reference\/Template_literals\" rel=\"noopener\">Template Literals<\/a><\/li>\n<\/ul>\n<p>If you&#8217;re the type that prefers jumping right to a working demo, here you go:<\/p>\n<p><a href=\"https:\/\/codepen.io\/bradwestfall\/project\/editor\/XWNWge\/?preview_height=50&#038;open_file=src\/app.js\" class=\"button\" rel=\"noopener\">View Demo<\/a><\/p>\n<h3>A New API and A New Mental Model<\/h3>\n<p>Earlier versions of React Router centralized the routing rules into one place, keeping them separate from layout components. Sure, the router could be partitioned and organized into several files, but conceptually the router was a unit, and basically a glorified configuration file. <\/p>\n<p>Perhaps the best way to see how v4 is different is to write a simple two-page app in each version and compare. The example app has just two routes for a home page and a user&#8217;s page.<\/p>\n<p>Here it is in v3: <\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">import { Router, Route, IndexRoute } from 'react-router'\r\n\r\nconst PrimaryLayout = props =&gt; (\r\n  &lt;div className=\"primary-layout\"&gt;\r\n    &lt;header&gt;\r\n      Our React Router 3 App\r\n    &lt;\/header&gt;\r\n    &lt;main&gt;\r\n      {props.children}\r\n    &lt;\/main&gt;\r\n  &lt;\/div&gt;\r\n)\r\n\r\nconst HomePage =() =&gt; &lt;div&gt;Home Page&lt;\/div&gt;\r\nconst UsersPage = () =&gt; &lt;div&gt;Users Page&lt;\/div&gt;\r\n\r\nconst App = () =&gt; (\r\n  &lt;Router history={browserHistory}&gt;\r\n    &lt;Route path=\"\/\" component={PrimaryLayout}&gt;\r\n      &lt;IndexRoute component={HomePage} \/&gt;\r\n      &lt;Route path=\"\/users\" component={UsersPage} \/&gt;\r\n    &lt;\/Route&gt;\r\n  &lt;\/Router&gt;\r\n)\r\n\r\nrender(&lt;App \/&gt;, document.getElementById('root'))<\/code><\/pre>\n<p>Here are some key concepts in v3 that are not true in v4 anymore:<\/p>\n<ul>\n<li>The router is centralized to one place.<\/li>\n<li>Layout and page nesting is derived by the nesting of <code>&lt;Route&gt;<\/code> components.<\/li>\n<li>Layout and page components are completely naive that they are a part of a router.<\/li>\n<\/ul>\n<p>React Router 4 does not advocate for a centralized router anymore. Instead, routing rules live within the layout and amongst the UI itself. As an example, here&#8217;s the same application in v4:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">import { BrowserRouter, Route } from 'react-router-dom'\r\n\r\nconst PrimaryLayout = () =&gt; (\r\n  &lt;div className=\"primary-layout\"&gt;\r\n    &lt;header&gt;\r\n      Our React Router 4 App\r\n    &lt;\/header&gt;\r\n    &lt;main&gt;\r\n      &lt;Route path=\"\/\" exact component={HomePage} \/&gt;\r\n      &lt;Route path=\"\/users\" component={UsersPage} \/&gt;\r\n    &lt;\/main&gt;\r\n  &lt;\/div&gt;\r\n)\r\n\r\nconst HomePage =() =&gt; &lt;div&gt;Home Page&lt;\/div&gt;\r\nconst UsersPage = () =&gt; &lt;div&gt;Users Page&lt;\/div&gt;\r\n\r\nconst App = () =&gt; (\r\n  &lt;BrowserRouter&gt;\r\n    &lt;PrimaryLayout \/&gt;\r\n  &lt;\/BrowserRouter&gt;\r\n)\r\n\r\nrender(&lt;App \/&gt;, document.getElementById('root'))<\/code><\/pre>\n<p class=\"explanation\"><strong>New API Concept<\/strong>: Since our app is meant for the browser, we need to wrap it in <code>&lt;BrowserRouter&gt;<\/code> which comes from v4. Also notice we import from <code>react-router-dom<\/code> now (which means we <code>npm install react-router-dom<\/code> not <code>react-router<\/code>). Hint! It&#8217;s called <code>react-router-dom<\/code> now because there&#8217;s also a <a href=\"https:\/\/reacttraining.com\/react-router\/native\" rel=\"noopener\">native version<\/a>.<\/p>\n<p>The first thing that stands out when looking at an app built with React Router v4 is that the &#8220;router&#8221; seems to be missing. In v3 the router was this giant thing we rendered directly to the DOM which orchestrated our application. Now, besides <code>&lt;BrowserRouter&gt;<\/code>, the first thing we throw into the DOM is our application itself.<\/p>\n<p>Another v3-staple missing from the v4 example is the use of  <code>{props.children}<\/code> to nest components. This is because in v4, wherever the <code>&lt;Route&gt;<\/code> component is written is where the sub-component will render to if the route matches.<\/p>\n<h3>Inclusive Routing<\/h3>\n<p>In the previous example, you may have noticed the <code>exact<\/code> prop. So what&#8217;s that all about? V3 routing rules were &#8220;exclusive&#8221; which meant that only one route would win. V4 routes are &#8220;inclusive&#8221; by default which means more than one <code>&lt;Route&gt;<\/code> can match and render at the same time. <\/p>\n<p>In the previous example, we&#8217;re trying to render either the <code>HomePage<\/code> or the <code>UsersPage<\/code> depending on the path. If the <code>exact<\/code> prop were removed from the example, both the  <code>HomePage<\/code> and <code>UsersPage<\/code> components would have rendered at the same time when visiting `\/users` in the browser.<\/p>\n<p class=\"explanation\">To understand the matching logic better, review <a href=\"https:\/\/www.npmjs.com\/package\/path-to-regexp\" rel=\"noopener\">path-to-regexp<\/a> which is what v4 now uses to determine whether routes match the URL.<\/p>\n<p>To demonstrate how inclusive routing is helpful, let&#8217;s include a <code>UserMenu<\/code> in the header, but only if we&#8217;re in the user&#8217;s part of our application:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const PrimaryLayout = () =&gt; (\r\n  &lt;div className=\"primary-layout\"&gt;\r\n    &lt;header&gt;\r\n      Our React Router 4 App\r\n      &lt;Route path=\"\/users\" component={UsersMenu} \/&gt;\r\n    &lt;\/header&gt;\r\n    &lt;main&gt;\r\n      &lt;Route path=\"\/\" exact component={HomePage} \/&gt;\r\n      &lt;Route path=\"\/users\" component={UsersPage} \/&gt;\r\n    &lt;\/main&gt;\r\n  &lt;\/div&gt;\r\n)<\/code><\/pre>\n<p>Now, when the user visits `\/users`, both components will render. Something like this was doable in v3 with certain patterns, but it was more difficult. Thanks to v4&#8217;s inclusive routes, it&#8217;s now a breeze.  <\/p>\n<h3>Exclusive Routing<\/h3>\n<p>If you need just one route to match in a group, use <code>&lt;Switch&gt;<\/code> to enable exclusive routing:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const PrimaryLayout = () =&gt; (\r\n  &lt;div className=\"primary-layout\"&gt;\r\n    &lt;PrimaryHeader \/&gt;\r\n    &lt;main&gt;\r\n      &lt;Switch&gt;\r\n        &lt;Route path=\"\/\" exact component={HomePage} \/&gt;\r\n        &lt;Route path=\"\/users\/add\" component={UserAddPage} \/&gt;\r\n        &lt;Route path=\"\/users\" component={UsersPage} \/&gt;\r\n        &lt;Redirect to=\"\/\" \/&gt;\r\n      &lt;\/Switch&gt;\r\n    &lt;\/main&gt;\r\n  &lt;\/div&gt;\r\n)<\/code><\/pre>\n<p>Only one of the routes in a given <code>&lt;Switch&gt;<\/code> will render. We still need <code>exact<\/code> on the <code>HomePage<\/code> route though if we&#8217;re going to list it first. Otherwise the home page route would match when visiting paths like `\/users` or `\/users\/add`. In fact, strategic placement is the name-of-the-game when using an exclusive routing strategy (as it always has been with traditional routers). Notice that we strategically place the routes for  <code>\/users\/add<\/code> before <code>\/users<\/code> to ensure the correct matching. Since the path <code>\/users\/add<\/code> would match for `\/users` and `\/users\/add`, putting the <code>\/users\/add<\/code> first is best.<\/p>\n<p>Sure, we could put them in any order if we use <code>exact<\/code> in certain ways, but at least we have options.<\/p>\n<p>The <code>&lt;Redirect&gt;<\/code> component will always do a browser-redirect if encountered, but when it&#8217;s in a  <code>&lt;Switch&gt;<\/code> statement, the redirect component only gets rendered if no other routes match first. To see how <code>&lt;Redirect&gt;<\/code> might be used in a non-switch circumstance, see <strong>Authorized Route<\/strong> below.<\/p>\n<h3>&#8220;Index Routes&#8221; and &#8220;Not Found&#8221;<\/h3>\n<p>While there is no more <code>&lt;IndexRoute&gt;<\/code> in v4, using <code>&lt;Route exact&gt;<\/code> achieves the same thing.  Or if no routes resolved, then use  <code>&lt;Switch&gt;<\/code> with <code>&lt;Redirect&gt;<\/code> to redirect to a default page with a valid path (as I did with <code>HomePage<\/code> in the example), or even a not-found page.<\/p>\n<h3>Nested Layouts<\/h3>\n<p>You&#8217;re probably starting to anticipate nested sub layouts and how you might achieve them. I didn&#8217;t think I would struggle with this concept, but I did. React Router v4 gives us a lot of options, which makes it powerful. Options, though, means the freedom to choose strategies that are not ideal. On the surface, nested layouts are trivial, but depending on your choices you may experience friction because of the way you organized the router. <\/p>\n<p>To demonstrate, let&#8217;s imagine that we want to expand our users section so we have a &#8220;browse users&#8221; page and a &#8220;user profile&#8221; page. We also want similar pages for products. Users and products both need sub-layout that are special and unique to each respective section. For example, each might have different navigation tabs. There are a few approaches to solve this, some good and some bad. The first approach is not very good but I want to show you so you don&#8217;t fall into this trap. The second approach is much better.<\/p>\n<p>For the first, let&#8217;s modify our <code>PrimaryLayout<\/code> to accommodate the browsing and profile pages for users and products:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const PrimaryLayout = props =&gt; {\r\n  return (\r\n    &lt;div className=\"primary-layout\"&gt;\r\n      &lt;PrimaryHeader \/&gt;\r\n      &lt;main&gt;\r\n        &lt;Switch&gt;\r\n          &lt;Route path=\"\/\" exact component={HomePage} \/&gt;\r\n          &lt;Route path=\"\/users\" exact component={BrowseUsersPage} \/&gt;\r\n          &lt;Route path=\"\/users\/:userId\" component={UserProfilePage} \/&gt;\r\n          &lt;Route path=\"\/products\" exact component={BrowseProductsPage} \/&gt;\r\n          &lt;Route path=\"\/products\/:productId\" component={ProductProfilePage} \/&gt;\r\n          &lt;Redirect to=\"\/\" \/&gt;\r\n        &lt;\/Switch&gt;\r\n      &lt;\/main&gt;\r\n    &lt;\/div&gt;\r\n  )\r\n}<\/code><\/pre>\n<p>While this does technically work, taking a closer look at the two user pages starts to reveal the problem:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const BrowseUsersPage = () =&gt; (\r\n  &lt;div className=\"user-sub-layout\"&gt;\r\n    &lt;aside&gt;\r\n      &lt;UserNav \/&gt;\r\n    &lt;\/aside&gt;\r\n    &lt;div className=\"primary-content\"&gt;\r\n      &lt;BrowseUserTable \/&gt;\r\n    &lt;\/div&gt;\r\n  &lt;\/div&gt;\r\n)\r\n\r\nconst UserProfilePage = props =&gt; (\r\n  &lt;div className=\"user-sub-layout\"&gt;\r\n    &lt;aside&gt;\r\n      &lt;UserNav \/&gt;\r\n    &lt;\/aside&gt;\r\n    &lt;div className=\"primary-content\"&gt;\r\n      &lt;UserProfile userId={props.match.params.userId} \/&gt;\r\n    &lt;\/div&gt;\r\n  &lt;\/div&gt;\r\n)<\/code><\/pre>\n<p class=\"explanation\"><strong>New API Concept:<\/strong> <code>props.match<\/code> is given to any component rendered by <code>&lt;Route&gt;<\/code>. As you can see, the <code>userId<\/code> is provided by <code>props.match.params<\/code>. See more in <a href=\"https:\/\/reacttraining.com\/react-router\/web\/example\/url-params\" rel=\"noopener\">v4 documentation<\/a>. Alternatively, if any component needs access to <code>props.match<\/code> but the component wasn&#8217;t rendered by a <code>&lt;Route&gt;<\/code> directly, we can use the <a href=\"https:\/\/reacttraining.com\/react-router\/web\/api\/withRouter\" rel=\"noopener\">withRouter()<\/a> Higher Order Component.<\/p>\n<p>Each user page not only renders its respective content but also has to be concerned with the sub layout itself (and the sub layout is repeated for each). While this example is small and might seem trivial, repeated code can be a problem in a real application. Not to mention, each time a <code>BrowseUsersPage<\/code> or <code>UserProfilePage<\/code> is rendered, it will create a new instance of <code>UserNav<\/code> which means all of its lifecycle methods start over. Had the navigation tabs required initial network traffic, this would cause unnecessary requests \u2014 all because of how we decided to use the router. <\/p>\n<p>Here&#8217;s a different approach which is better:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const PrimaryLayout = props =&gt; {\r\n  return (\r\n    &lt;div className=\"primary-layout\"&gt;\r\n      &lt;PrimaryHeader \/&gt;\r\n      &lt;main&gt;\r\n        &lt;Switch&gt;\r\n          &lt;Route path=\"\/\" exact component={HomePage} \/&gt;\r\n          &lt;Route path=\"\/users\" component={UserSubLayout} \/&gt;\r\n          &lt;Route path=\"\/products\" component={ProductSubLayout} \/&gt;\r\n          &lt;Redirect to=\"\/\" \/&gt;\r\n        &lt;\/Switch&gt;\r\n      &lt;\/main&gt;\r\n    &lt;\/div&gt;\r\n  )\r\n}<\/code><\/pre>\n<p>Instead of four routes corresponding to each of the user&#8217;s and product&#8217;s pages, we have two routes for each section&#8217;s layout instead.<\/p>\n<p class=\"explanation\">Notice the above routes do not use the <code>exact<\/code> prop anymore because we want <code>\/users<\/code>  to match any route that starts with <code>\/users<\/code> and similarly for products.<\/p>\n<p>With this strategy, it becomes the task of the sub layouts to render additional routes. Here&#8217;s what the <code>UserSubLayout<\/code> could look like:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const UserSubLayout = () =&gt; (\r\n  &lt;div className=\"user-sub-layout\"&gt;\r\n    &lt;aside&gt;\r\n      &lt;UserNav \/&gt;\r\n    &lt;\/aside&gt;\r\n    &lt;div className=\"primary-content\"&gt;\r\n      &lt;Switch&gt;\r\n        &lt;Route path=\"\/users\" exact component={BrowseUsersPage} \/&gt;\r\n        &lt;Route path=\"\/users\/:userId\" component={UserProfilePage} \/&gt;\r\n      &lt;\/Switch&gt;\r\n    &lt;\/div&gt;\r\n  &lt;\/div&gt;\r\n)<\/code><\/pre>\n<p>The most obvious win in the new strategy is that the layout isn&#8217;t repeated among all the user pages. It&#8217;s a double win too because it won&#8217;t have the same lifecycle problems as with the first example.<\/p>\n<p>One thing to notice is that even though we&#8217;re deeply nested in our layout structure, the routes still need to identify their full path in order to match. To save yourself the repetitive typing (and in case you decide to change the word &#8220;users&#8221; to something else), use <code>props.match.path<\/code> instead:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const UserSubLayout = props =&gt; (\r\n  &lt;div className=\"user-sub-layout\"&gt;\r\n    &lt;aside&gt;\r\n      &lt;UserNav \/&gt;\r\n    &lt;\/aside&gt;\r\n    &lt;div className=\"primary-content\"&gt;\r\n      &lt;Switch&gt;\r\n        &lt;Route path={props.match.path} exact component={BrowseUsersPage} \/&gt;\r\n        &lt;Route path={`${props.match.path}\/:userId`} component={UserProfilePage} \/&gt;\r\n      &lt;\/Switch&gt;\r\n    &lt;\/div&gt;\r\n  &lt;\/div&gt;\r\n)<\/code><\/pre>\n<h3>Match<\/h3>\n<p>As we&#8217;ve seen so far, <code>props.match<\/code> is useful for knowing what <code>userId<\/code> the profile is rendering and also for writing our routes. The <code>match<\/code> object gives us several properties including <code>match.params<\/code>, <code>match.path<\/code>, <code>match.url<\/code> and <a href=\"https:\/\/reacttraining.com\/react-router\/web\/api\/match\" rel=\"noopener\">several more<\/a>. <\/p>\n<h4><strong>match.path<\/strong> vs <strong>match.url<\/strong><\/h4>\n<p>The differences between these two can seem unclear at first. Console logging them can sometimes reveal the same output making their differences even more unclear. For example, both these console logs will output the same value when the browser path is `\/users`:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const UserSubLayout = ({ match }) =&gt; {\r\n  console.log(match.url)   \/\/ output: \"\/users\"\r\n  console.log(match.path)  \/\/ output: \"\/users\"\r\n  return (\r\n    &lt;div className=\"user-sub-layout\"&gt;\r\n      &lt;aside&gt;\r\n        &lt;UserNav \/&gt;\r\n      &lt;\/aside&gt;\r\n      &lt;div className=\"primary-content\"&gt;\r\n        &lt;Switch&gt;\r\n          &lt;Route path={match.path} exact component={BrowseUsersPage} \/&gt;\r\n          &lt;Route path={`${match.path}\/:userId`} component={UserProfilePage} \/&gt;\r\n        &lt;\/Switch&gt;\r\n      &lt;\/div&gt;\r\n    &lt;\/div&gt;\r\n  )\r\n}<\/code><\/pre>\n<p class=\"explanation\"><strong>ES2015 Concept:<\/strong> <code>match<\/code> is being <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Reference\/Operators\/Destructuring_assignment\" rel=\"noopener\">destructured<\/a> at the parameter level of the component function. This means we can type <code>match.path<\/code> instead of <code>props.match.path<\/code>.<\/p>\n<p>While we can&#8217;t see the difference yet, <code>match.url<\/code> is the actual path in the browser URL and <code>match.path<\/code> is the path written for the router. This is why they are the same, at least so far. However, if we did the same console logs one level deeper in <code>UserProfilePage<\/code> and visit `\/users\/5` in the browser, <code>match.url<\/code> would be <code>\"\/users\/5\"<\/code> and <code>match.path<\/code> would be <code>\"\/users\/:userId\"<\/code>.<\/p>\n<h3>Which to choose?<\/h3>\n<p>If you&#8217;re going to use one of these to help build your route paths, I urge you to choose <code>match.path<\/code>. Using <code>match.url<\/code> to build route paths will eventually lead a scenario that you don&#8217;t want. Here&#8217;s a scenario which happened to me. Inside a component like <code>UserProfilePage<\/code> (which is rendered when the user visits `\/users\/5`), I rendered sub components like these:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const UserComments = ({ match }) =&gt; (\r\n  &lt;div&gt;UserId: {match.params.userId}&lt;\/div&gt;\r\n)\r\n\r\nconst UserSettings = ({ match }) =&gt; (\r\n  &lt;div&gt;UserId: {match.params.userId}&lt;\/div&gt;\r\n)\r\n\r\nconst UserProfilePage = ({ match }) =&gt; (\r\n  &lt;div&gt;\r\n    User Profile:\r\n    &lt;Route path={`${match.url}\/comments`} component={UserComments} \/&gt;\r\n    &lt;Route path={`${match.path}\/settings`} component={UserSettings} \/&gt;\r\n  &lt;\/div&gt;\r\n)<\/code><\/pre>\n<p>To illustrate the problem, I&#8217;m rendering two sub components with one route path being made from <code>match.url<\/code> and one from <code>match.path<\/code>. Here&#8217;s what happens when visiting these pages in the browser: <\/p>\n<ul>\n<li>Visiting `\/users\/5\/comments` renders &#8220;UserId: undefined&#8221;.<\/li>\n<li>Visiting `\/users\/5\/settings` renders &#8220;UserId: 5&#8221;.<\/li>\n<\/ul>\n<p>So why does <code>match.path<\/code> work for helping to build our paths and <code>match.url<\/code> doesn&#8217;t? The answer lies in the fact that <code>{${match.url}\/comments}<\/code> is basically the same thing as if I had hard-coded <code>{'\/users\/5\/comments'}<\/code>.  Doing this means the subsequent component won&#8217;t be able to fill <code>match.params<\/code> correctly because there were no params in the path, only a hardcoded <code>5<\/code>.<\/p>\n<p>It wasn&#8217;t until later that I saw <a href=\"https:\/\/reacttraining.com\/react-router\/core\/api\/match\" rel=\"noopener\">this part of the documentation<\/a> and realized how important it was:<\/p>\n<blockquote><p>\nmatch: <\/p>\n<ul>\n<li>path &#8211; (string) The path pattern used to match. <strong>Useful for building nested <code>&lt;Route&gt;<\/code>s<\/strong><\/li>\n<li>url &#8211; (string) The matched portion of the URL. <strong>Useful for building nested <code>&lt;Link&gt;<\/code>s<\/strong><\/li>\n<\/ul>\n<\/blockquote>\n<h3>Avoiding Match Collisions<\/h3>\n<p>Let&#8217;s assume the app we&#8217;re making is a dashboard so we want to be able to add and edit users by visiting `\/users\/add` and `\/users\/5\/edit`. But with the previous examples, <code>users\/:userId<\/code> already points to a <code>UserProfilePage<\/code>. So does that mean that the route with <code>users\/:userId<\/code> now needs to point to yet another sub-sub-layout to accomodate editing and the profile? I don&#8217;t think so. Since both the edit and profile pages share the same user-sub-layout, this strategy works out fine:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const UserSubLayout = ({ match }) =&gt; (\r\n  &lt;div className=\"user-sub-layout\"&gt;\r\n    &lt;aside&gt;\r\n      &lt;UserNav \/&gt;\r\n    &lt;\/aside&gt;\r\n    &lt;div className=\"primary-content\"&gt;\r\n      &lt;Switch&gt;\r\n        &lt;Route exact path={props.match.path} component={BrowseUsersPage} \/&gt;\r\n        &lt;Route path={`${match.path}\/add`} component={AddUserPage} \/&gt;\r\n        &lt;Route path={`${match.path}\/:userId\/edit`} component={EditUserPage} \/&gt;\r\n        &lt;Route path={`${match.path}\/:userId`} component={UserProfilePage} \/&gt;\r\n      &lt;\/Switch&gt;\r\n    &lt;\/div&gt;\r\n  &lt;\/div&gt;\r\n)<\/code><\/pre>\n<div class=\"explanation\">\n<p>Notice that the add and edit routes strategically come before the profile route to ensure there the proper matching. Had the profile path been first, visiting `\/users\/add` would have matched the profile (because &#8220;add&#8221; would have matched the <code>:userId<\/code>.<\/p>\n<p>Alternatively, we can put the profile route first if we make the path <code>${match.path}\/:userId(\\\\d+)<\/code> which ensures that <code>:userId<\/code> must be a number. Then visiting `\/users\/add` wouldn&#8217;t create a conflict. I learned this trick in the docs for <a href=\"https:\/\/github.com\/pillarjs\/path-to-regexp#custom-match-parameters\" rel=\"noopener\">path-to-regexp<\/a>.<\/p>\n<\/div>\n<h3>Authorized Route<\/h3>\n<p>It&#8217;s very common in applications to restrict the user&#8217;s ability to visit certain routes depending on their login status. Also common is to have a &#8220;look-and-feel&#8221; for the unauthorized pages (like &#8220;log in&#8221; and &#8220;forgot password&#8221;) vs the &#8220;look-and-feel&#8221; for the authorized ones (the main part of the application). To solve each of these needs, consider this main entry point to an application:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">class App extends React.Component {\r\n  render() {\r\n    return (\r\n      &lt;Provider store={store}&gt;\r\n        &lt;BrowserRouter&gt;\r\n          &lt;Switch&gt;\r\n            &lt;Route path=\"\/auth\" component={UnauthorizedLayout} \/&gt;\r\n            &lt;AuthorizedRoute path=\"\/app\" component={PrimaryLayout} \/&gt;\r\n          &lt;\/Switch&gt;\r\n        &lt;\/BrowserRouter&gt;\r\n      &lt;\/Provider&gt;\r\n    )\r\n  }\r\n}<\/code><\/pre>\n<p class=\"explanation\">Using <a href=\"https:\/\/github.com\/reactjs\/react-redux\" rel=\"noopener\">react-redux<\/a> works very similarly with React Router v4 as it did before, simply wrap <code>&lt;BrowserRouter&gt;<\/code> in <code>&lt;Provider&gt;<\/code> and it&#8217;s all set.<\/p>\n<p>There are a few takeaways with this approach. The first being that I&#8217;m choosing between two top-level layouts depending on which section of the application we&#8217;re in. Visiting paths like `\/auth\/login` or `\/auth\/forgot-password` will utilize the <code>UnauthorizedLayout<\/code> \u2014 one that looks appropriate for those contexts. When the user is logged in, we&#8217;ll ensure all paths have an `\/app` prefix which uses <code>AuthorizedRoute<\/code> to determine if the user is logged in or not. If the user tries to visit a page starting with `\/app` and they aren&#8217;t logged in, they will be redirected to the login page.<\/p>\n<p><code>AuthorizedRoute<\/code> isn&#8217;t a part of v4 though. I made it myself <a href=\"https:\/\/reacttraining.com\/react-router\/web\/example\/auth-workflow\" rel=\"noopener\">with the help of v4 docs<\/a>. One amazing new feature in v4 is the ability to create your own routes for specialized purposes. Instead of passing a <code>component<\/code> prop into <code>&lt;Route&gt;<\/code>, pass a <code>render<\/code> callback instead:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">class AuthorizedRoute extends React.Component {\r\n  componentWillMount() {\r\n    getLoggedUser()\r\n  }\r\n\r\n  render() {\r\n    const { component: Component, pending, logged, ...rest } = this.props\r\n    return (\r\n      &lt;Route {...rest} render={props =&gt; {\r\n        if (pending) return &lt;div&gt;Loading...&lt;\/div&gt;\r\n        return logged\r\n          ? &lt;Component {...this.props} \/&gt;\r\n          : &lt;Redirect to=\"\/auth\/login\" \/&gt;\r\n      }} \/&gt;\r\n    )\r\n  }\r\n}\r\n\r\nconst stateToProps = ({ loggedUserState }) =&gt; ({\r\n  pending: loggedUserState.pending,\r\n  logged: loggedUserState.logged\r\n})\r\n\r\nexport default connect(stateToProps)(AuthorizedRoute)<\/code><\/pre>\n<p>While your login strategy might differ from mine, I use a network request to <code>getLoggedUser()<\/code> and plug <code>pending<\/code> and <code>logged<\/code> into Redux state. <code>pending<\/code> just means the request is still in route.<\/p>\n<p>Click here to see a fully working <a href=\"https:\/\/codepen.io\/bradwestfall\/project\/editor\/XWNWge\/?preview_height=50&#038;open_file=src\/app.js\" rel=\"noopener\">Authentication Example at CodePen<\/a>.<\/p>\n<figure><a href=\"https:\/\/codepen.io\/bradwestfall\/project\/editor\/XWNWge\/?preview_height=50&#038;open_file=src\/app.js\" rel=\"noopener\"><img decoding=\"async\" src=\"https:\/\/i0.wp.com\/res.cloudinary.com\/css-tricks\/image\/upload\/f_auto,q_auto\/v1502066098\/rr4_jmydzy.gif?ssl=1\" alt=\"\" data-recalc-dims=\"1\"><\/a><\/figure>\n<h3>Other mentions<\/h3>\n<p>There&#8217;s a lot of other cool aspects React Router v4. To wrap up though, let&#8217;s be sure to mention a few small things so they don&#8217;t catch you off guard. <\/p>\n<h4><strong>&lt;Link><\/strong> vs <strong>&lt;NavLink><\/code><\/strong><\/h4>\n<p>In v4, there are two ways to integrate an anchor tag with the router: <a href=\"https:\/\/reacttraining.com\/react-router\/web\/api\/Link\" rel=\"noopener\"><code>&lt;Link&gt;<\/code><\/a> and <a href=\"https:\/\/reacttraining.com\/react-router\/web\/api\/NavLink\" rel=\"noopener\"><code>&lt;NavLink&gt;<\/code><\/a><\/p>\n<p><code>&lt;NavLink&gt;<\/code> works the same as <code>&lt;Link&gt;<\/code> but gives you some extra styling abilities depending on if the <code>&lt;NavLink&gt;<\/code> matches the browser&#8217;s URL. For instance, in the <a href=\"https:\/\/codepen.io\/bradwestfall\/project\/editor\/XWNWge\/#\" rel=\"noopener\">example application<\/a>, there is a <code>&lt;PrimaryHeader&gt;<\/code> component that looks like this:<\/p>\n<pre rel=\"JavaScript\"><code class=\"language-javascript\">const PrimaryHeader = () =&gt; (\r\n  &lt;header className=\"primary-header\"&gt;\r\n    &lt;h1&gt;Welcome to our app!&lt;\/h1&gt;\r\n    &lt;nav&gt;\r\n      &lt;NavLink to=\"\/app\" exact activeClassName=\"active\"&gt;Home&lt;\/NavLink&gt;\r\n      &lt;NavLink to=\"\/app\/users\" activeClassName=\"active\"&gt;Users&lt;\/NavLink&gt;\r\n      &lt;NavLink to=\"\/app\/products\" activeClassName=\"active\"&gt;Products&lt;\/NavLink&gt;\r\n    &lt;\/nav&gt;\r\n  &lt;\/header&gt;\r\n)<\/code><\/pre>\n<p>The use of <code>&lt;NavLink&gt;<\/code> allows me to set a class of <code>active<\/code> to whichever link is active. But also, notice that I can use <code>exact<\/code> on these as well. Without <code>exact<\/code> the home page link would be active when visiting `\/app\/users` because of the inclusive matching strategies of v4. In my personal experiences, <code>&lt;NavLink&gt;<\/code> with the option of <code>exact<\/code> is a lot more stable than the v3 <code>&lt;Link&gt;<\/code> equivalent. <\/p>\n<h4>URL Query Strings<\/h4>\n<p>There is no longer way to get the query-string of a URL from React Router v4. It seems to me that the <a href=\"https:\/\/github.com\/ReactTraining\/react-router\/issues\/4410\" rel=\"noopener\">decision was made<\/a> because there is no standard for how to deal with complex query strings. So instead of v4 baking an opinion into the module, they decided to just let the developer choose how to deal with query strings. This is a good thing.<\/p>\n<p>Personally, I use <a href=\"https:\/\/www.npmjs.com\/package\/query-string\" rel=\"noopener\">query-string<\/a> which is made by the always awesome <a href=\"https:\/\/twitter.com\/sindresorhus\" rel=\"noopener\">sindresorhus<\/a>.<\/p>\n<h4>Dynamic Routes<\/h4>\n<p>One of the best parts about v4 is that almost everything (including <code>&lt;Route&gt;<\/code>) is just a React component. Routes aren&#8217;t magical things anymore. We can render them conditionally whenever we want. Imagine an entire section of your application is available to route to when certain conditions are met. When those conditions aren&#8217;t met, we can remove routes. We can even do some crazy cool <a href=\"https:\/\/reacttraining.com\/react-router\/web\/example\/recursive-paths\" rel=\"noopener\">recursive route<\/a> stuff. <\/p>\n<p>React Router 4 is easier because it&#8217;s <a href=\"https:\/\/youtu.be\/Mf0Fy8iHp8k?t=3m22s\" rel=\"noopener\">Just Components&#x2122;<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>This post is going to dig into to React Router 4, how it&#8217;s so different from previous React Router versions, and why that is. My intentions for this article aren&#8217;t to rehash the <a href=\"https:\/\/reacttraining.com\/react-router\/\">already well-written documentation<\/a> for React Router 4. I will cover the most common API concepts, but the real focus is on patterns and strategies that I&#8217;ve found to be successful.<\/p>\n","protected":false},"author":230276,"featured_media":257464,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":[]},"categories":[4],"tags":[557,625],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/08\/logo-react-router.png?fit=1156%2C542&ssl=1","jetpack-related-posts":[],"featured_media_src_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/08\/logo-react-router.png?fit=1024%2C480&ssl=1","_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/257428"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/users\/230276"}],"replies":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/comments?post=257428"}],"version-history":[{"count":20,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/257428\/revisions"}],"predecessor-version":[{"id":285599,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/257428\/revisions\/285599"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media\/257464"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=257428"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=257428"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=257428"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}