[V6] [Feature]: Support absolute paths in descendant `<Routes>`

[Patrik-Lundqvist]

What is the new or updated feature that you are suggesting?

Great to see that absolute paths will be supported in V6, I find it very handy to work with.

For it to be fully supported I believe it should work when using nested <Routes> as well.

const App = () => (
  <Routes>
    <Route path="/users/*" element={<Users />} />
  </Routes>
);

const Users = () => (
  <Routes>
    <Route path="/users/:id/settings" element={<UserSettings />} />
  </Routes>
);

Currently (v6.0.0-beta.4) the route definition in the nested <Routes> will match on a relative route, even though they start with / indicating an absolute route.

Why should this feature be included?

This way we can use absolute paths throughout our application when we don't specify all routes in the same <Routes> component. This will also make the migration from v5 to v6 much easier as this pattern is supported there using <Switch>.

[timdorr]

I'm not sure if this makes sense. If you want to use your Users routes in multiple places, you wouldn't be able to. Not to mention Links/NavLinks would be harder to reason about.

We treat the the route context that you render your Route within as a "basename" of sorts. That enables you to not have to worry about the context you're within when creating your Routes tree. It's easy enough to reason about absolute routes when they're all being rendered within the same component. But if you spread that out over different files or modules (or heck, even different repos), it becomes harder to keep track of it all.

Realistically, this is less about the Users component and more about the App component. How does the App component know the Users routes aren't going to escape the path App thinks they are nested under? That might be surprising at best and error-inducing at worst. I could understand some sort of escape hatch API, such as an absolute prop, but I'd be hesitant to add it. It feels like a footgun.

[Patrik-Lundqvist]

I agree that isolating each routing context will make the components more reusable and should probably be the preferred way of doing things. But I also see the use of having routes specified in one place which then can be used by both <Link> and <Route>, especially in applications that have a lot of cross-cutting links and isn't on the "multiple repos" scale.

If this is not at all desired then I agree that an escape hatch might at least be a way ease the migration from v5 -> v6. Like stated here its somewhat common and quite a painful rewrite to do, but perhaps its necessary.

Thank you for the great work that's being done here 👍

[openscript]

I've already been posting about this in #7972, but I agree, that this was probably the wrong place to mention this. Hopefully now I'm on the spot.

The feature which @Patrik-Lundqvist is asking for, already existed in version v6.0.0-beta.1 but stopped working in v6.0.0-beta.2. Here is a working reproduction with version v6.0.0-beta.1: https://github.com/openscript/react-router-nested-routes-bug

Steps to reproduce:

1. Install dependencies and start project (yarn install and yarn start)
2. Go to http://localhost:3000/customer/users
3. Click on Next page (absolute)
4. The URL should be http://localhost:3000/customer/users/10/2

With the branch not-working and v6.0.0-beta.2 the URL will be: http://localhost:3000/10/2

[timdorr]

BTW, you can open that in your browser with Codesandbox: https://codesandbox.io/s/github/openscript/react-router-nested-routes-bug

[openscript]

It's a neat feature from codesandbox, but it never worked for me:

:(

[julioflima]

BTW, you can open that in your browser with Codesandbox: https://codesandbox.io/s/github/openscript/react-router-nested-routes-bug

Thanks, I was getting a cold sweat. I was having a problem not adding the slash after the path like: "users" to "users/".

I got the error:

Error: Absolute route path "/" nested under path "/users" is not valid. An absolute child route path must start with the combined path of all its parent routes.
useRoutes/matches<
/home/juliolima/packages/react-router/index.tsx:1012

But may you should update this, that way is not working at all.
https://reacttraining.com/blog/react-router-v6-pre/

    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="users" element={<Users />}>
          <Route path="/" element={<UsersIndex />} />
          <Route path=":id" element={<UserProfile />} />
          <Route path="me" element={<OwnUserProfile />} />
        </Route>
      </Routes>
    </BrowserRouter>

[thedanwoods]

I agree that this is a necessary feature. Giving a <Routes> a magic basename that doesn't respect a leading / is counterintuitive, and means we can't use path constants properly.

If we want to use absolute paths, we have to do everything in the same component:

<Routes>
  <Route path="/clothes" element={<Clothes />}>
    <Route path="/clothes/shirt" element={<Shirt />} />
    <Route path="/clothes/trousers" element={<Trousers />} />
  </Route>
</Routes>

...

const Clothes = () => (
  <>
    Clothes page
    <Outlet />
  </>
);

and we can't break it down into sub-routes components like this:

<Routes>
  <Route path="/clothes/*" element={<Clothes />}></Route>
</Routes>

...

// This doesn't work, as it will try to match /clothes/clothes/shirt
const Clothes = () => (
  <>
    Clothes page
    <Routes>
      <Route path="/clothes/shirt" element={<Shirt />} />
      <Route path="/clothes/trousers" element={<Trousers />} />
    </Routes>
  </>
);

The use cases are:

(1) We use constants for pathnames, to always guarantee a <Link to={PATH_CONSTANT}> takes us to <Route path={PATH_CONSTANT}>. Without this feature, we can't use PATH_CONSTANT - we have to use something else.

(2) In a large application, if a developer is told there's a bug in /some/old/obsucre/page, a simple text search for "/some/old/obsucre/page" immediately tells them what's being rendered.

(3) We organise our app in modules, and code-split by module, and don't want to put everything in an enormous top-level <AllTheRoutes /> component.

[osddeitf]

It's exciting to see React Router reach v6. But...
As stated in https://remix.run/blog/react-router-v6:

Note: Absolute paths still work in v6 to help make upgrading easier. You can even ignore relative paths altogether and keep using absolute paths forever if you'd like. We won't mind.

I went all the way to upgrade my project to v6, but absolute path wouldn't work.
It's pain in the *ss for me to use relative path, it's counter-intuitive.

[openscript]

I would love to get started to work on this. It would help me a lot if somebody can outline a broad idea how and where to implement this.

[ryanflorence]

We justified supporting absolute paths in nested route configs, seems like the same reasoning applies here. It would also help migration from v5.

Unless @mjackson wants to talk me out of it, I'm all for it.

[jampy]

Any news on this?

[jampy]

What about extendeding the <Routes> component with something like fromRoot that forgets everything about parent <Routes>?

Implementation in react-routes should be easy, I think, as it simply means to ignore parent matches.

Upgrading from v5 would be much easier (just add another prop):

const Clothes = () => (
  <>
    Clothes page
    <Routes fromRoot>    // <---- "fromRoot" makes this independent from parent <Routes> elements
      <Route path="/clothes/shirt" element={<Shirt />} />
      <Route path="/clothes/trousers" element={<Trousers />} />
    </Routes>
  </>
);

Children <Routes> in <Shirt/> could then still be relative unless fromRoot is used there, too.

BTW, I would strongly suggest to add a __DEV__ warning whenever a <Route> matches a path with leading / but is relative to a parent route. It took me a while to figure out why my absolute routes did not work while upgrading from v4. IMHO relative matches to a absolute link notation are unintuitive.