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

[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.

[jampy]

Here is a similar, hacky solution.

<RootRoutes> is a drop-in replacement for <Routes> that ignores parent routes, with the effect of treating all <Route> as absolute.

import { UNSAFE_RouteContext as RouteContext } from 'react-router';

function RootRoutes(props) {

  const ctx = useContext(RouteContext);

  const value = useMemo(
    () => ({
      ...ctx,
      matches: []
    }),
    [ ctx ]
  );

  return <RouteContext.Provider
    value={value}
  >
    <Routes {...props}/>
  </RouteContext.Provider>;

}

But please note this makes use of "undocumented" react-router API and should not be used except for testing.

I still plead for a dedicated parameter for standard <Routes>.

[Kayeeec]

Just an FYI - this solution is not working for me in "react-router": "^6.22.3" 😿

EDIT: it works (in my project only kind of). The mistake was in my code, see my comment below.

[puopg]

@Kayeeec Have you tried this approach?

#9841 (comment)

Check the codesanbox to see if this is the flavor you are looking for

[Kayeeec]

Alright, after I commented I noticed the code sandbox - forked it, changed the react-router version and it worked.
So the problem was in my code. After finally reading the console warnings properly, I discovered that the parent route (defined in the parent <Routes>, has to end with '/*' for it to work.

Example:

{/* parent component, e.g. App.tsx */}
<Routes>
  {/* other routes... */}
  <Route path="/submodule/*" />
</Routes>

{/* some deeper child component */}
<Routes>
  {/* other routes... */}
  <Route path="/submodule/subpage" />
</Routes>

But I still have some other bugs with this solution. My links that travel deeper into the routes tree, using absolute paths, often lose the route parameters - so far IDK why.

Anyway, @puopg thanks for your reply 😸

[Below just a rant]

Seriously, I'm contemplating either using relative paths or using a completely different routing library altogether out of spite. Absolute paths should be a standard feature - if it starts with '/' = absolute, else relative. That's the standard understanding of paths in any SW (filesystems, HTML etc.). What were they thinking? Relative routes are a nightmare in a bigger project.

I mean I do have an idea for a tree-like data structure to hold relative routes and their absolute versions to make the rewrite easier BUT IT SUCKS THAT IT'S EVEN NEEDED. That's what a library is for. To make routing easier.

[lvilasboas-dti]

I literally could not agree more with your rant - seriously, what were they thinking???

[mkarajohn]

All true.

[henrywoody]

@jampy Support for absolute paths in nested <Route> components was discussed in #7335 and added in #7992, seems the approach for absolute paths in descendant <Route> components should follow the same pattern.

Edit: To make this more clear, by "should" I mean "when implemented" rather than "currently".

[jampy]

@henrywoody thanks for your reply! Good to know.

I've checked the PR and also the documentation, but I fail to understand how this is supposed to work. Do I need to specify something special to make nested absolute paths work?

My base component looks something like this:

function Application() {

  return <Routes>
    <Route path="/info/*" element={<InfoModule/>} />
    /* ... */
    <Route path="*" element={<Navigate to="/"/>} />
  </Routes>;

}

and the nested routes look basically like this:

function InfoModule() {

  return <Routes>
    <Route path="/info/" element={<WelcomePage/>} />
    <Route path="/info/docs/*" element={<DocsBrowser/>} />
  </Routes>;

}

However, neither <WelcomePage> nor <DocsBrowser> render with this config (but <InfoModule> does).

Logging useLocation() in InfoModule shows {pathname: '/info', search: '', hash: '', state: null, key: '3cuoedw8'} or {pathname: '/info/docs', search: '', hash: '', state: null, key: 'default'} when I manually change the URL hash (I'm using HashRouter). They look good to me.

Swapping <Routes> with my <RootRoutes> hack above makes the routes render as intended, OTOH.

What am I doing wrong?

[lvilasboas-dti]

Almost a year has gone by since this issue has been opened, a ton of users have presented strong arguments on this as well, and absolutely no answer so far...

[JakeSidSmith]

For my use cases I only require matching an absolute path from a flat list of Routes and rendering an element, so we're using the following. It ain't too smart but maybe peeps can modify it to support more features.

import {ReactElement} from 'react';
import {matchPath, useLocation} from 'react-router-dom';

// Allows matching `Route`s against absolute paths when they are nested under another `Route`
// See: https://github.com/remix-run/react-router/issues/8035
const AbsoluteRoutes = ({children}: {children?: readonly ReactElement[]}) => {
  const {pathname} = useLocation();

  return (
    children?.find(
      child =>
        typeof child.props.path === 'string' &&
        matchPath(child.props.path, pathname),
    )?.props.element ?? null
  );
};

export {AbsoluteRoutes};

[hvolschenk]

For the meantime I ended up with these two methods to keep my absolute paths (sort of):

export const urlLayout = (url: string): string => `${url}/*`;
export const urlRelative = (url: string, parent: string): string => url.replace(parent, '');

I have created a sample sandbox of how they are used here: codesandbox.

[justinbhopper]

V6 has conflicting philosophies in its new Path architecture.

In one hand, absolute paths are heavily embraced by utilizing the power of TypeScript's Template Literal types, even to the point of removing heavily used features.

On the other hand, absolute paths (and template literal types) are discouraged because nested routes simply don't work with them at all.

[brophdawg11]

I'm going to convert this to a discussion so it can go through our new Open Development process. Please upvote the new Proposal if you'd like to see this considered!

[vertic4l]

This is such a crucial feature which is currently missing by many. Hope you get this implemented soon. In the meantime we are going to use the RootRoutes workaround.

[mghdmi]

I've just wanted to define a routes config for our project routes and found this issue.
I'm using 6.3.0

I have this config for example:

const routes = {
  AUTH: {
    path: '/auth',
    children: { LOGIN: '/auth/login', OTP: '/auth/otp' }
  },
};

function App() {
  return (
    <Routes>
      <Route path={`${routes.AUTH.path}/*`} element={<Auth />} />
    <Routes>
  )
}

function Auth() {
  return (
    <Routes>
      <Route element={<Layout />}>
        <Route index element={<Welcome />} />
        <Route path={routes.AUTH.children.LOGIN} element={<Login />} />
        <Route path={routes.AUTH.children.OTP} element={<OTP />} />
      </Route>
    </Routes>
  )
}

Absolute paths doesn't work in nested <Routes />

[PinkaminaDianePie]

Spent a lot of time debugging this.
It's not intuitive.
It breaks the composition rules - now the order matters. If I have a hierarchy of components like A => B, A could use absolute paths, while B couldn't. If I change the order to B => A, everything breaks
It makes it MUCH harder to write your own helpers around react-router (like a component that takes URL and renders both Routes and a button to navigate, with relative paths it becomes a mess).
It makes it more costly to develop, due to the issue above
It makes it more costly to maintain, due to the issue above

You won't convince me that "it's by design" if it makes it more costly to write and maintain the code while providing no benefits. It can't be by design. That's just a bug. Please fix it if it's possible

[lvilasboas-dti]

9 months since my last reply saying that "almost a year had gone by", and still no progress.
@PinkaminaDianePie summarized greatly how counter intuitive this "by-design feature" is, and still nothing.

Please, either mark this as "will not do" or give us some meaningful update. It's mesmerizing that:

1. react-router is one of the most used React libs
2. and given that, the fact that such an impactful bug has being going around for so long.

[donaldpipowitch]

I read the migration guide in the React Router docs from v5 to v6 a couple of times, but I never figured out that nesting of <Routes/> and the usage of absolute paths is not supported. The <RootRoutes/> workaround helps us as well. Thanks for sharing. It would have been wonderful if the migration guide would include this.

[osddeitf]

Well, it passed the 2-years-milestone since the last time I commented on this issue. It's also been a while since I used react-router in my projects. And now I see this still an issue.

The overall ideas of v6 just made sense to me when I first read and tried it. But it's such a shame absolute paths are not supported.
Let's take a look at how base url are implemented in Web standards.

• <base> element: The <base> HTML element specifies the base URL to use for all relative URLs in a document. There can be only one element in a document.
• new URL(url, [base]): If url is a relative URL, base is required, and will be used as the base URL. If url is an absolute URL, a given base will be ignored.

My point is that this react-router library took a wrong move not to support absolute paths feature.
V6 seemed to be more elegant than V5, which was a good sight, but it SURE is counter-productive without absolute paths. As @thedanwoods have made excellent examples:

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.

I'm not so free myself but I think I'm willing to challenge myself adding support for absolute paths.

[lvilasboas-dti]

hope you get it! but more than that, I wish you luck getting your PR merged, since the team behind react-router apparently doesn't give a single drop of importance to this issue

[puopg]

Dude let me know if you need help. I havent upgraded for a year now due to this, but now we need R18. And guess what isnt compatible with R18, yup RRv5

[puopg]

Not tested thouroughly though seems to work?, just decided to try out the hack provided above. Its awesome that it works, but kinda weird since theres warnings in development. I tried doing something like this, since I have no basename set things are defaulted to "/", but in case it assists anyone else.

import React, { useContext } from "react";
import { UNSAFE_RouteContext as RouteContext } from "react-router";
import { matchRoutes, Route, Routes, useLocation } from "react-router-dom";

type Props = {
  children: React.ReactNode;
};

const AbsolutePathRoutes = (props: Props): React.ReactElement => {
  // Copy context from RouteContext above. 
  const routeContext = useContext(RouteContext);
  const location = useLocation();

  // Create a fake match for the root route
  // https://github.com/remix-run/react-router/blob/426b055ad7d569f12cc2f19d48875081477a67fe/packages/react-router/lib/hooks.tsx#L361
  const rootMatch = {
    params: {},
    pathname: "/",
    pathnameBase: "/",
    route: {
      path: "/",
    },
  };

  // Do I need to do this? lol iono
  // const routes = React.Children.toArray(props.children);
  // const matchesBasedOnCurrentLocation = matchRoutes(routes, location) || [];

  // Insert the rootMatch at the end so RR always thinks its matching at least the root.
  const value = {
    ...routeContext,
    matches: [rootMatch],
  };

  // Essentially clone and modify the route context to make it seem like its the root lol.
  return (
    <RouteContext.Provider value={value}>
      <Routes {...props} />
    </RouteContext.Provider>
  );
};

export default AbsolutePathRoutes;

Codesandbox so you can play with it: https://codesandbox.io/p/sandbox/react-router-v6-forked-nkmr2w

[dorsharonfuse]

This issue seems to be still ongoing in v6.20.1.
Is there no official solution for using absolute paths in nested Routes?

This is one of the most used React libs out there, and the most popular routing lib, and we're not given any kind of addressing from the maintainers? really?

[lvilasboas-dti]

right???
It's been well over a year since I mentioned this - is completely and utterly astonishing that the maintainers have not said anything whatsoever.

[Leolainen]

I found this passage in the FAQ.

function MatchPath({ path, Comp }) {
  let match = useMatch(path);
  return match ? <Comp {...match} /> : null;
}

// Will match anywhere w/o needing to be in a `<Routes>`
<MatchPath path="/accounts/:id" Comp={Account} />;

It seems to work the same as <Route> from react-router 5. A real saviour in our very large microFE monorepo project.

edit:
I didn't realise at first but this solution renders any components that match. For example, the paths /products/:productId and /products/sale will both match and thus render both components on the same page.

[mkarajohn]

I am trying to move over to v6 from v5 and I have faced the same issue.

In our case we are keeping every URL of the project in a static object, eg

export const paths = {
  home: () => '/home',
  admin: () => '/admin',
  adminPage1: () => paths.admin() + '/page1',
  adminPage2: () => paths.admin() + '/page2',
}

This is a very useful pattern because we can use these paths for links or as path props to Route components, and changing them once changes them everywhere.

As you can see, these are absolute paths and this does not mix well with how descendant Routes handle the path as being relative.

For example we have a specific Routes component only for admins, which has Routes that only point to admin links, e.g.

function AdminRoutes() {
  return (
    <Routes>
      <Route path={paths.adminPage1()} element={...} />
    </Routes>
  );
}

Which we then render inside our main Routes component, like this:

function Routes() {
  return (
    <Routes>
      <Route path={paths.admin() + '/*'} element={<AdminRoutes />} />
    </Routes>
  );
}

With the way things work right now the <Route path={paths.adminPage1()} element={...} /> never matches because it tries to match /admin/admin/page1 instead of matching /admin/page1

The way we have setup our project we cannot be working with relative paths, so an official way to match paths as absolute would be nice. @timdorr @ryanflorence

EDIT:
essentially case 1 + 2 from @thedanwoods 's comment #9841 (comment)