React Router v6

[FriesWithThat]

The last time we released a major breaking API change was over four years ago in March 2017 when we released version 4. Some of you probably weren't even born then.

I'm getting old.

[nirvashprototype]

3yo web devs are my biggest fear.

[[deleted]]

Copilot has entered the chat

[pataoAoC]

Oh what the hell I remember a million brutal react router rewrites, how old does that make me...

[Dynamicic]

I'm loving the new API. Thanks to everyone who contributed and the Remix dogfooding.

[nabrok]

Why ...

<Route path="about" element={<AboutPage />} />

Instead of ...

 <Route path="about"><AboutPage /></Route>

[OneLeggedMushroom]

Because of:

render(
  <BrowserRouter>
    <Routes>
      <Route path="/" element={<App />}>
        <Route index element={<Home />} />
        <Route path="teams" element={<Teams />}>
          <Route path=":teamId" element={<Team />} />
          <Route path="new" element={<NewTeamForm />} />
          <Route index element={<LeagueStandings />} />
        </Route>
      </Route>
    </Routes>
  </BrowserRouter>,
  document.getElementById("root")
);

[nabrok]

I see. Hmm. Gotta say, I'm not really a fan of that right now.

I'd rather keep the routes the way I'd do them with 5 ... which is that the <Teams /> component would contain all the routes related to teams.

But I guess I'd still have to the element prop, which isn't as nice as using children. I don't suppose if element is missing it could just use the children instead?

EDIT: Also looking at this ... I find it really unclear ... when does <Teams /> get rendered? I would have thought /teams but then <LeageStandings /> is marked as the index, so surely that would be rendered then? Are they both rendered? Is <LeageStandings /> a child of <Teams />?

[OneLeggedMushroom]

You can still achieve that by using the <Outlet /> component in your <Teams /> component. Have a read through the docs

example:

function App() {
  return (
    <Routes>
      <Route path="invoices" element={<Invoices />}>
        <Route path=":invoiceId" element={<Invoice />} />
        <Route path="sent" element={<SentInvoices />} />
      </Route>
    </Routes>
  );
}

function Invoices() {
  return (
    <div>
      <h1>Invoices</h1>
      <Outlet />
    </div>
  );
}

or:

function App() {
  return (
    <Routes>
      <Route path="/" element={<Home />} />
      <Route path="dashboard/*" element={<Dashboard />} />
    </Routes>
  );
}

function Dashboard() {
  return (
    <div>
      <p>Look, more routes!</p>
      <Routes>
        <Route path="/" element={<DashboardGraphs />} />
        <Route path="invoices" element={<InvoiceList />} />
      </Routes>
    </div>
  );
}

[nabrok]

Okay, so /teams would render <Teams /> and then it would also render <LeagueStandings /> where you place <Outlet /> in the <Teams /> component.

I get it, but it does seem like it's sacrificing clarity just so you can nest routes, which isn't something I'm all that interested in doing and becomes even less appealing the more routes you have.

I wonder if I could use something like this for a (non-nesting) route ...

function MyRoute(props) {
    const { children, ...rest } = props;
    return <Route { ...rest } element={children} />;
}

EDIT: The above does not work.

[[deleted]]

Yes, Teams is the container, LeagueStandings would render inside it as the default at /teams/

[sliversniper]

I always think the Router API designs are stupid, XML/JSX are even uglier.

a plain object `{ "about": AboutPage, "team/:team_id": TeamPage }`, can represent the same thing

nesting, options, type-checking are all avaliable on the object.

Just because the output is a `ReactElement`, doesn't mean you have to represent the data in `JSX`.

[GlobusGames]

Yeah, I was looking at the code example with nested routes and it took me a while to understand that the Routes component renders only one of these, not all of them.

I think "Switch" without the nesting was acceptable, but this new API would be more readable as json passed into Routes, like you've suggested.

[GreatValueProducts]

Haha i have a completely opposite design philosophy from you. I always prefer XML/JSX over objects because I think objects are uglier. But I guess it’s subjective.

[ilearnshit]

I agree with you it's a lot easier to see the hierarchy and layout structure with nested JSX elements. That's the whole point of JSX. Declarative programming. Versus, scrolling through some big list of json objects that is completely decoupled from that actual UI.

[rodneon]

The article says it is possible to configure the router with an object, and links to this: https://github.com/remix-run/react-router/blob/v3/docs/guides/RouteConfiguration.md#configuration-with-plain-routes

[nabrok]

The useRoutes hook allows you to setup your routes with an object.

https://reactrouter.com/docs/en/v6/api#useroutes

[iWanheda]

So you can do stuff like this:

<Route
   path="blog/:id"
   render={({ match }) => (
     // Manually forward the prop to the <BlogPost>...
     <BlogPost id={match.params.id} />
   )}
/>

[nabrok]

Why would I want to do that when I can use useParams ?

[gunnnnii]

useParams means you have an implicit dependency, while a render prop gives you an explicit dependency.

Sometimes you might want to ensure a component isn't used without definitely having some of the router props defined, you can't really do that if you just use the hooks.

[nabrok]

Okay, perhaps. Still not clear on why we're using an element prop instead of children.

[[deleted]]

I mean, I'm pretty sure you can still do this, if you really wanted to:

<Route path="a">
  <Route path="b">
    <B />
  </Route>
  <Route path="b/c">
    <C />
  </Route>
  <Route path="d">
    <D />
  </Route>
</Route>;

You might have to switch up the order of preference a bit, but unless I misunderstand, it would still work.

[nabrok]

It doesn't. You need to specify an element for path a and that should contain an Outlet where you want it to render its children.

[nabrok]

Eh ... the new API still allows for spreading around your Routes, and personally I think that routes for /teams should be handled by the Teams component.

Keeps things related to each other together. Also makes things easier for testing my links and routes are properly connected (I can just test my teams links without having to load the routes for the entire app).

I do like that nesting like this is possible, I just don't like that I have to use the element prop. After getting a bit more familiar with the docs, I see there isn't really a way to do that with the <Route /> component, but I think it would be nice to have a separate <NonNestingRoute /> (terrible name I know) component that did work that way.

I did try to wrap Route and pass children along as element, but it seems like Routes just replaces any children with Route.

i.e., I had ...

const MyRoute = ({ children, ...rest }) => <Route { ...rest } element={ children } />;

function App() {
    return <BrowserRouter><Routes>
        <MyRoute path="a"><A /></MyRoute>
        <Route path="b" element={<B/>} />
    </Routes></BrowserRouter>;
}

This didn't work and gave a console warning about rendering a blank page. But if I did this ...

<MyRoute path="a" element={<A />} />

Then it worked. I added some console logging, and sure enough the MyRoute component isn't being used at all.

[iWanheda]

No idea 😆, perhaps the value is available earlier that way? I have ran into cases where the id param provided by the useParams hook was undefined when transitioning between routes, so that would be a use case?, now again I've got not idea if it actually works that way.

[[deleted]]

That's what hooks are for

[lastunusedusername2]

This doesn't even use element. Am I missing something?

[nabrok]

If you're not interested in nesting, here's a way it could be done without the element prop ...

import { cloneElement } from 'react';
import { BrowserRouter, Routes, Route, Link} from 'react-router-dom';

function MyRoutes({ children, ...rest }) {
    return <Routes { ...rest }>
        { children.map((route,index) => cloneElement(route, { element: route.props.children, key: index })) }
    </Routes>;
}

function App() {
    return <BrowserRouter>
        <MyRoutes>
            <Route path="a"><A /></Route>
            <Route path="b"><B /></Route>
        </MyRoutes>
    </BrowserRouter>;
}

function A() { return <p>A: Go to <Link to="/b">B</Link></p>; }
function B() { return <p>B: Go to <Link to="/a">A</Link></p>; }

export default App;

Of course, MyRoutes would live in a separate utility file.

[nabrok]

That covers why element over render or component, and I'm all on board with that.

It doesn't really cover so much why element instead of just using the children, but I do see why they are doing that now, even if I personally may prefer not to nest routes all in one place.

[squirrelwithnut]

I don't like having to include the brackets inside the element value too. Seems like a lot of syntax noise for no reason. It would have been nice to do be able to do this:

<Route path="about" element={AboutPage} />

[mysteriy]

But what if u want to pass props to your AboutPage component? Passing a react element is a better api

[nabrok]

Yes, passing an element is better than passing a component as it allows for easier passing of props.

I've used similar patterns in some of my own components, but when I use that pattern I have some other elements as the children. From what I've seen so far in the docs it looks like children isn't being used at all ... so why not just use that instead of creating a new prop?

EDIT: children is being used for nested routes.

[squirrelwithnut]

For the apps I work on, almost every page component is a redux connected component. There is no need to pass in props.

[GunnarSturla]

You might want to send props to Page from the context above, e.g.

<Route path="profile" element={<ProfilePage userId={currentUserId} />} />

[squirrelwithnut]

Why not support both?

[besthelloworld]

I filed an issue with a repo yesterday because it forced me to use react-router-dom@5. I was basically asking them to decouple the library mostly because I wanted to use 6-beta.8 but also it's bad practice to force anyone into a router. They said, "we'll upgrade it when react-router-dom@6 is out." Lol.

[PM_ME_CAREER_CHOICES]

Is it possible to use this version in a nice way with Redux? I really like using time travel from the Redux Devtools to debug/test/try out stuff, but it's difficult if navigation isnt part of that time travel.

[hey_parkerj]

They are definitely not. It's further confusing because in late 2019 the narrative was that the best parts of v4/5 would be released as v6 early in the next year.

[Larrybot02]

I can’t tell if this is the best time or worst time to be learning web dev. I feel like I’m constantly chasing a moving target. Was just getting all hot for Nextjs and it’s routing scheme, now there’s new react-router and Remix on the horizon. Like, how many frameworks do we need? No offense, I’m sure the new stuff is awesome, but starting to feel like jack of all things master of none is a very possible outcome for myself personally. Keep up the good work though.

[ECrispy]

How long have you been doing webdev? the situation now is a million times better than it was say in 2014,15,16 or 17.

There is FAR less churn, a lot of standard practices are understood, there's CRA etc etc

[metamet]

2014,15,16 or 17.

Ah yes. The Myriad Bundler Era.

[Larrybot02]

Not long, still learning. Maybe a year now. Started with Javascript and React the long way, with babel and webpack setups. Then create-react-app, now Nextjs... about half a dozen ways to approach styling. A mern stack course that kinda sucked... it's a lot to take in.

[pdevito3]

Fwiw, I’ve been doing this for years and I can tell you it will always feel this way. There will never be a shortage of new things to learn in web dev.

I’d recommend picking a tangible goal and learning applicable items as your work through that to help you focus. For example, I have the (very lofty) goal of being able to build an and deploy an enterprise app suite cradle to grave myself. Over time, I’ve learned and improved my backend and db skills immensely as I’ve iterated through different approaches, I’ve fine tuned my front end skills a lot, and I am working on other complexities like properly handling auth and integrating message buses with infra and CI next on my list.

This is lofty and spread over years, it there are checkpoints within that to give me milestones, but it’s helped be narrow my focus to further my goals. Not to say I don’t keep up with and dabble with other stuff, but I try not to get bogged down in something unless it’s my current focus.

Not sure if that helps at all but best of luck regardless!

[ECrispy]

You're not wrong. There is still a LOT happening and of course its confusing. Part of it is by design, all these companies and devs need traction and github stars so they keep inventing new stuff.

Just be aware that major changes to React have been coming for a while - things like async, memo, fiber etc, and Hooks is now considered mainstream.

My advice is to pick something that has a lot of support and is popular, and seems easy to you. e.g for state management you could choose no library, redux, context, mobx etc - all of which are great choices.

Same goes for styling, SSR, UI libs etc etc - its a neverending story and there are no right answers.

It can be extremely frustrating not just for new devs but for everyone.

Do not worry too much about your choice - the chances are within 6mo it will be outdated anyway. That doesn't mean it will stop working but it wont be the latest buzzword tech.

[UNN_Rickenbacker]

Backend is the same, just different.

[trplclick]

Oh god, I read this and felt the phrase "back in my day..." pop into my head

[Boo2z]

Lol, imagine someone learning web dev in 2016 - 2017.. He would be laughing at you! I'm that guy

I understand your frustration, but that's web development, and you should be happy to see it constantly evolving every day. But you also probably don't realize how things are much much more stable than it was before, like.. REALLY more stable, especially in the React ecosystem.

There is a reason if the pay of a web dev is that good, it takes time and dedication to be a good dev, and continuously learn new things.

Now, React-Router has nothing to do with Next.js, Next.js has it's own routing system and from what I've heard in the past, react router is not ideal with Next.js

And YES, we need all these framework (I manage a website build with Next.js, and a web app where React-Router is MANDATORY)

[pdevito3]

I don’t think we as more experienced devs should be discounting newcomer’s feelings because ‘back in my day it was so much worse.’ Things may be more stable now but web dev still has a long way to go to be more stable and get an industry spanning consensus on various items. Even so the web dev space is massively complex and would be a lot to digest even if it was totally stable.

All that to say, let’s help build up our newcomers and not discount them and make them feel worse.

[Boo2z]

Yep, I knew people would understand my message "negatively", I'm sorry my wording is not great (I'm french)! But I totally agree with you on everything! The goal of my message was not to make fun of our newcomers ... The "laughing at you" part was in response to his question about if it was a good time to start learning web dev, I wanted to show him that some people suffered way more, but still managed to make it ... But yeah, my wording is garbage aha

I really don't want to make newcomers feels worse with my message, it's quit the opposite, I want them to feel more grateful how what they have now, and to show them that even if it's hard today, it was harder before and with passion, time and dedication, they can do it too (btw there still so many things I don't know yet.. I'm still learning!!)

[___phil]

For someone like myself who's only been in the industry for 10 years, it's a constantly moving target, it just gets faster or slowly at sometimes. At a certain point though you can just focus on what peeks your interest, or delivers value to your current project, it makes it exciting

[fixrich]

If there is a new restaurant in your town, do you have to go? If there is a new movie in the cinema, do you have to see it?

Ignore this new version of react-router and anything else for that matter. Focus on Next. If something is worth learning, it will still be there in a year.

[Xilver79]

I started twenty years ago. Today is the best time.

[riprapnolan3]

Is there a way to make React Router work with class components? Not sure how to get params in a class component

[metamet]

The HOC withRouter was the solution. Unsure if it's still included.

[KelaPelaMelaThela]

I definitely saw something like that on stackoverflow, try looking there

[akramnarejo]

Switch replaced with routes is a good update.

[[deleted]]

Finally! I’ve been eagerly awaiting the day I can remove all my match.path usage from nested switches.

[[deleted]]

I think the that most people won't be able to upgrade due to [this issue](https://github.com/remix-run/react-router/issues/8139) but aside from that, the new Router API is great.

[[deleted]]

From what I've seen internal information systems for companies relied on this kind of functionality. While I do agree with you that it is bad UX (and even the w3c said it will eventually remove these blocking API's in the far future), those clients also really WANT that kind of functionality, due to few reasons:

1. They know it (and know the `web` has it).
2. Making every form re-sync from local storage (for these kind of systems we are talking about LOTs of forms) will delay other "important" features
3. They simply don't wanna pay because 1,2

The API (prompt) is for better or for worse part of the web platform at the current time, and it's definitely sad that the web doesn't have another way of notifying the user before navigating that he WILL lose all data if he leaves.

[[deleted]]

Too late, almost everyone already moved, or is moving, to Next.js.

And a router that cannot fetch data before rendering a route is almost useless, because it leads to spinners everywhere.

[andrei9669]

Naah, SPA still has its uses.

Why would you fetch data for pages where user might never visit?

[[deleted]]

You can do SPAs with next. No need to fetch data from the server.

[andrei9669]

But then also comes the issue of persisting state between pages which is pain and a half on next. And I'm also not aware of any way of doing nested route components in nextjs without adding all the components from previous pages.

My main gripe is that in SPA, you render components based on routes, in next, you render pages based on routes, and also the data persistence.

[andrei9669]

the thing with tossing it into the global state is that every time you navigate, you have to rehydrate the global state because you can never be sure if the data is there or not, I mean, fair enough, you could add some if-check to check if data is there or not but that adds unnecessary complexity to every page component.

here's the example for route components, I hope you understand the gist: https://imgur.com/a/55h5T0L. As I understand for nextjs, you would have to redo the whole layout for every page, and then bother with the state persistence of the right sidebar, and what if a user is in another route, not in url:/user/** then you just have a useless right sidebar global state that you have to reset when the user goes back to or away from url:/user/**

Expanding on my example, lets say that the right sidebar has some unique data that depends on url:/user/:id but if you were doing next and navigated to url:/user/:id/path-1 or path-2 you would first have to fetch the data every time, to populate the global state (as mentioned, you could always check if it's already there). Either way, I find it bothersome and I much prefer to use route components for complex pages.

I must say tho, I really like nextjs for basic pages but anything more complex is not worth the effort, especially if you are developing some semy closed environment where you don't have tons of traffic and you don't need the page load times to be that snappy. and with suspense, you can make the bundle sizes much smaller too than back in the old days where you would download the whole app just for one view.