<AbsoluteRoutes>

[ryanflorence]

In v5 deeply nested <Route path="/absolute/path"> matched the parent portion of the URL, but in v6 deeply nested <Routes> build upon the previous path and won't match an absolute path.

To facilitate easier migrations to v6 as well as allow people to have centralized route tables with absolute paths, you can use <AbsoluteRoutes> as a replace for <Routes>.

For example:

// High up the tree:

<Routes>
  <Route path="admin/*" />
</Routes>

// ✅ deeper in the tree uses relative paths that build on /admin/
<Routes>
  <Route path="users" />
  <Route path="settings" />
</Routes>

// ❌ does not work today
<Routes>
  <Route path="/admin/users" />
  <Route path="/admin/settings" />
</Routes>

// ✅ will work now with AbsoluteRoutes
<AbsoluteRoutes>
  <Route path="/admin/users" />
  <Route path="/admin/settings" />
</AbsoluteRoutes>

Again, this will facilitate migrations from v5 as well as allow folks to use centralized route tables:

const routes = {
  admin: "/admin/*",
  users: "/admin/users/:userId"
}

<Routes>
  <Route path={routes.admin} />
</Routes>

// and then inside the tree of the admin route
<AbsoluteRoutes>
  <Route path={routes.users} />
</AbsoluteRoutes>

[ivosabev]

Instead of increasing the API surface with a new AbsoluteRoute, why not just make all routes absolute if starting with a /?

[ryanflorence]

That's how it works when it's not a "descendent <Routes>". For example, this works fine:

      <Routes>
        <Route path="/" />
        <Route path="/admin">
          <Route path="/admin/users" />
        </Route>
      </Routes>

It's when it's rendered later.

Maybe we could change a bunch of the context internals, but this little component can be done w/o changing anything, in fact it could done in userland. Always a tradeoff, we'd rather not mess with how context/matching work when the behavior can be composed instead.