Skip to content

Instantly share code, notes, and snippets.

@mjackson
Last active June 21, 2024 01:54
Show Gist options
  • Save mjackson/d54b40a094277b7afdd6b81f51a0393f to your computer and use it in GitHub Desktop.
Save mjackson/d54b40a094277b7afdd6b81f51a0393f to your computer and use it in GitHub Desktop.
Notes on route composition in React Router v6, along with a suggested improvement you can make today to start upgrading

Composing <Route> in React Router v6

Composition of <Route> elements in React Router is changing in v6 from how it worked in v4/5 and in Reach Router. React Router v6 is the successor of both React Router v5 and Reach Router.

This document explains our rationale for making the change as well as a pattern you will want to avoid in v6 and a note on how you can start preparing your v5 app for v6 today.

Background

In React Router v5, we had an example of how you could create a <PrivateRoute> element to restrict access to certain routes on the page. This element was a simple wrapper around an actual <Route> element that made a simple decision: is the user authenticated or not? If so, render the children prop. Otherwise, render a <Redirect> to the login page.

It looked something like this:

import { Switch, Route, Redirect } from "react-router-dom";

function App() {
  return (
    <Switch>
      <Route path="/public">
        <PublicPage />
      </Route>
      <PrivateRoute path="/protected" redirectTo="/login">
        <ProtectedPage />
      </PrivateRoute>
    </Switch>
  );
}

function PrivateRoute({ path, children, redirectTo }) {
  let isAuthenticated = getAuth();
  return (
    <Route
      path={path}
      render={() => (
        isAuthenticated ? children : <Redirect to={redirectTo} />
      )}
    />
  );
}

When it came time to render, the <Switch> would treat your <ProtectedRoute> component the same as a normal <Route> element.

This is because <Switch>, unlike most React components, uses the props of its children to decide which ones to render. This is a little non-standard, but children is just a prop after all. So it's not too different from deciding what to render based on any other prop you receive. In the case of <Switch>, it actually looks through the paths of all its children to figure out which ones match the current URL, and then it renders the ones that do.

If you were using Reach Router, The <Router> component worked similarly to v5's <Switch>. Except it took this one step further and eliminated the <Route> component altogether and just used your own custom components instead for convenience.

The Problem

The problem is that when you create a wrapper around a <Route> element, whether it's a v5-style <ProtectedRoute> component or a Reach Router custom component, these components must expect all the props of <Route> in addition to any other props they receive. This becomes particularly painful if you're using TypeScript (or propTypes, remember those?) to declare your component interface.

In the case of our <PrivateRoute> component above, the TypeScript declaration for its props would be an intersection of its own props and those of <Route>:

interface PrivateRouteProps {
  redirectTo: string;
}

function PrivateRoute(props: RouteProps & PrivateRouteProps) {
  // ...
}

The problem was even more apparent when using TypeScript with Reach Router where you didn't have a <Route> component and every one of your custom route components was required to accept all route props as well as its own.

import { Router } from "@reach/router";

function App() {
  return (
    <Router>
      <HomePage path="/" />
      <AboutPage path="/about" />
    </Router>
  );
}

function HomePage(props: RouteProps & HomePageProps) {
  // ...
}

function AboutPage(props: RouteProps & AboutPageProps) {
  // ...
}

Not only is the props type declaration messy, but in the majority of cases your route components are receiving props that they don't actually do anything with. Why? Because these props were meant for <Route>, not them.

<Route> Composition in React Router v6

React Router v6 introduces a new <Routes> element that replaces <Switch>. One of the main advantages of <Routes> over <Switch> is its ability to understand nested <Route> elements, much like we did in React Router v3. We'll write more about just how cool <Routes> is in the official v6 docs.

In v6, <Route> is a lot more strict than it was in v5. Instead of building wrappers for <Route>, it may be used only inside other <Routes> or <Route> elements. If you try to wrap a <Route> in another component like PrivateRoute it will never render. So any custom logic you have in PrivateRoute will never run. If you try to render a <PrivateRoute> as a standalone <Route> (i.e. outside a <Switch>) it will throw an error.

function PrivateRoute(props) {
  // BAD. This code will never run!
  return <Route {...props} />;
}

Instead of creating wrappers for your <Route> elements to get the functionality you need, you should do all your own composition in the <Route element> prop.

Taking the example from above, if you wanted to protect certain routes from non-authenticated users in React Router v6, you could do something like this:

import { Routes, Route, Navigate } from "react-router-dom";

function App() {
  return (
    <Routes>
      <Route path="/public" element={<PublicPage />} />
      <Route
        path="/protected"
        element={
          // Good! Do your composition here instead of wrapping <Route>.
          // This is really just inverting the wrapping, but it's a lot
          // more clear which components expect which props.
          <RequireAuth redirectTo="/login">
            <ProtectedPage />
          </RequireAuth>
        }
      />
    </Routes>
  );
}

function RequireAuth({ children, redirectTo }) {
  let isAuthenticated = getAuth();
  return isAuthenticated ? children : <Navigate to={redirectTo} />;
}

Notice how in this example the RequireAuth component doesn't expect any of <Route>'s props. This is because it isn't trying to act like a <Route>. Instead, it's just being rendered inside a <Route>.

Get Started Upgrading Today

If you want to get a head start on upgrading your React Router v5 app to v6 today, you can eliminate any custom route components in your <Switch>es and just use plain <Route>s instead. Then, do your composition inside the <Route render> prop.

To continue with the initial example, you could rewrite your v4/5 code today to look like this:

import { Switch, Route, Redirect } from "react-router-dom";

function App() {
  return (
    <Switch>
      <Route path="/public">
        <PublicPage />
      </Route>
      <Route
        path="/protected"
        render={() => (
          <RequireAuth redirectTo="/login">
            <ProtectedPage />
          </RequireAuth>
        )}
      />
    </Switch>
  );
}

function RequireAuth({ children, redirectTo }) {
  let isAuthenticated = getAuth();
  return isAuthenticated ? children : <Redirect to={redirectTo}>;
}

When you finally do upgrade to v6, convert <Route render={() => ...}> to <Route element={...}> and you're done.

@Naureen13
Copy link

Here you say "When you finally do upgrade to v6, convert <Route render={() => ...}> to and you're done." and inside the documentation for upgrading v5 to v6 you say : "Use instead of and/or props" . So what is the right way to upgrade this part ?

Exactly! I have the same question, I have seen a lot conflicts information while migrating from v5 to v6.

Hii, did you get any solution for this as I am facing the same problem right now.

@mickelindahl
Copy link

mickelindahl commented Feb 12, 2024

Hi, I had a wrapper for Route in which we types path to a sepcific set of url:s that is eligable in our project. This feature was very appriated since it made it difficult to create a route that was not in stored in route types object. So I would suggest that you allowed for wrappers again since with the current setup it is impossible to type path to Routes since it is not possible wrap it and add extra typeing to the input. Do not understand why you opted away from this neat feature. Would have been great if it had been kept since it made our life easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment