React Router DOM: set-up, essential components, & parameterized routes

To specify the URL that corresponds to each component, you use the <Route> in the following way:

<Route path="/" component={Home}/>
<Route path="/messages" component={Messages}/>
<Route path="/about" component={About}/>

With other router libraries (and even in previous versions of React Router), you have to define these routes in a special file, or at least, outside your application.

This doesn’t apply to React Router 4. These components can be placed anywhere inside of the router, and the associated component will be rendered in that place, just like any other component.

So in src/App.js, import all these components and add a section after the menu:

In the browser, you should see something like this:

However, look what happen when you go to the other routes:

By default, routes are inclusive, more than one <Route> component can match the URL path and render at the same time.

Routes are the most important concept in React Router, and you need to know some things about them.

Let’s talk about routes in the next section.

Understanding routes

The matching logic of the <Route> component is delegated to the path-to-regexp library. I encourage you to check all the options and modifiers of this library and test it live with the express-route-tester.

In the previous example, since the /message and /about paths also contain the character /, they are also matched and rendered.

With this behavior, you can display different components just by declaring that they belong to the same (or similar) path.

There’s more than one solution.

The first one uses the exact property to render the component only if the defined path matches the URL path exactly:

<Route exact path="/" component={Home}/>

If you test the application, you’ll see that everything works fine.

The routes /message and /about are still evaluated, but they are not an exact match for / now.

However, if we know that only one route will be chosen, we can use a <Switch> component to render only the first route that matches the location:

<Switch> will make the path matching exclusive rather than inclusive (as if you were using <Route> components).

For example, even if you duplicate the route for the Messages component:

<Switch>
  <Route exact path="/" component={Home} />
  <Route path="/messages" component={Messages} />
  <Route path="/messages" component={Messages} />
  <Route path="/about" component={About} />
</Switch>

When visiting the /messages path, the Messages component will be rendered only once.

However, notice that you’ll still need to specify the exact property for the /path, otherwise, /message and /about will also match /, and the Homecomponent will always be rendered (since this is the first route matched):

But what happens when a non-existent path is entered? For example http://localhost:3000/non-existent:

In a regular JavaScript switch statement, you’ll specify a default clause for this case, right?

In a <Switch> component, this default behavior can be implemented with a <Redirect> component:

This component will navigate to a new location overriding the current one in the history stack:

Now, let’s cover something a little more advanced, nested routes.

Nested routes

A nested route is something like /about/react.

Let’s say that for the messages section, we want to display a list of messages. Each one in the form of a link like /messages/1, /messages/2, and so on, that will lead you to a detail page.

You can start by modifying the Messages component to generate links for five sample messages in this way:

This should be displayed in the browser:

To understand how to implement this, you need to know that when a component is rendered by the router, three properties are passed as parameters:

• match
• location
• history

For our purposes, we’ll be using the match parameter.

Get a Free Trial of LogRocket

Sick of debugging web apps? Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket pairs session replay with technical telemetry to quickly understand what went wrong.

Get a Free Trial of LogRocket

Sign up with GitHub

Sign up with Google

or

Sign Up

When there’s a match between the router’s path and the URL location, a `match` object is created with information about the URL and the path. Here are the properties of this object:

• params. Key/value pairs parsed from the URL corresponding to the parameters.
• isExact. true if the entire URL was matched (no trailing characters).
• path. The path pattern used to match.
• url. The matched portion of the URL.

This way, in the Messages component, we can destructure the properties object to use the match object:

const Messages = ({ match }) => (
<div>
...
</div>
)

Replace /messages with the matched URL of the match object: 

This way you’re covered if the path ever changes.

And after the message list, declare a <Route component with a parameter to capture the message identifier:

In addition, you can enforce a numerical ID in this way:

<Route path={`${match.url}/:id(\\d+)`} component={Message} />

If there’s a match, the Message component will be rendered. Here’s its definition:

In this component, the ID of the message is displayed. Notice how the ID is extracted from the match.params object using the same name that it’s defined in the path.

If you open the browser, you should see something similar to the following:

But notice that for the initial page of the messages section (/messages) or if you enter in the URL and invalid identifier (like /messages/a), nothing is printed under the list. A message would be nice, don’t you think?

You can add another route for this case, but instead of creating another component to just display a message, we can use the render property of the <Route> component:

<Route
  path={match.url}
  render={() => <h3>Please select a message</h3>
/>

You can define what is rendered by using one of the following properties of <Route>:

• component. To render a component.
• render. A function that returns the element or component to be rendered.
• children. A function that also returns the element or component to be rendered. However, the returned element is rendered regardless of whether the path is matched or not.

Finally, we can wrap the routes in a <Switch> component to guarantee that only one of the two is matched:

However, you have to be careful. If you declare route that renders the message first:

The Message component will never be rendered because a path like /messages/1 will match the path /messages.

If you declare the routes in this order, add exact to avoid this behavior:

Conclusion

In a few words, a router keeps your application UI and the URL in sync.

React Router is the most popular router library for React, and since version 4, React Router declarative defines routes with components, in the same style than React.

In this post, you have learned how to set up React Router, its most important components, how routes work, and how to build dynamic nested routes with path parameters.

But there’s still a lot of more to learn. For example, there a <NavLink>component that is a special version of the <Link> component that adds the properties activeClassName and activeStyle to give you styling options when the link matches the location URL.

The official documentation covers some basic as well as more advanced, interactive examples. Also, don’t forget to check out the advanced React Router concepts post, here on LogRocket’s blog.