[Bug]: Relative navigation issue while navigating from "index" route: ".." doesn't works, I must use "../.." to go back

[Gryndii]

What version of React Router are you using?

6.0.2

Steps to Reproduce

<Some other routes>
....
<Route path='/pages'>
    <Route index element={<Pages />} />

    <Route path=':pageId' element={<Item />} />              
  </Route>
  

Navigation via '..' from Pages with "index" doesn't works but it is ok for Item
I should use '../..' for the same result as '..'

Expected Behavior

Should navigate level up via '..' from index route
And it would be nice to have option with nested routes that is used only to create url hierarchy for relative navigation usage, but without children and parrents ui rendering

Actual Behavior

doesnt navigate from index page via '..'

[maxandriani]

I'm struggling w/ the same issue, but I think the root cause is because the "base" url should contains a trailing slash, otherwise the history dependency will compute the relative path wrong.

The problems appears to be in the resolve-pathname.js -> resolve-pathname -> history -> react-router dependency.

In the line 30, the algorithm just consider everything in the same level as a filename string w/o check if it is really a filename string (file.ext).

[mrlika]

I think it is because .. means navigate one <Route> up in the routes tree and not one path segment (directory) up. Consider this example:

function NavigateUp() {
  return <Navigate to='..' />;
}

<Route path='/test'>
  <Route path=':a/:b/:c' element={<NavigateUp />} />
  <Route path=':a' element={<NavigateUp />} />
</Route>

Both /test/a/b/c and /test/a are redirected to /test because one route up in the tree is <Route path='/test'> that is really weird. I can't find this in documentation.

[gowthamvbhat]

Both /test/a/b/c and /test/a are redirected to /test that is really weird. I can't find this in documentation.

@mrlika This is discussed here - upgrading to v6.

[mrlika]

@gowthamvbhat, thanks for pointing out that. As for me, it is better to write unlike <a href> that goes up by path segments.

[mrlika]

The workaround is to use resolvePath that has no relation to <Route> tree:

const navigate = useNavigate();
navigate(resolvePath('..', window.location.pathname));

// or

<Link to={resolvePath('..', window.location.pathname)} />

// or

<Navigate to={resolvePath('..', window.location.pathname)} />

[Huulivoide]

Seems that a route match gets generated for both the parent route and the nested index route.
Matches array of RouteContext:

(5) [{…}, {…}, {…}, {…}, {…}]
0: {params: {…}, pathname: '/', pathnameBase: '/', route: {…}}
1: {params: {…}, pathname: '/person', pathnameBase: '/person', route: {…}}
2: {params: {…}, pathname: '/person/203876', pathnameBase: '/person/203876', route: {…}}
3:
    params: {personId: '203876'}
    pathname: "/person/203876/items"
    pathnameBase: "/person/203876/items"
    route: {caseSensitive: undefined, element: {…}, index: undefined, path: 'items', children: Array(4)}
4:
    params: {personId: '203876'}
    pathname: "/person/203876/items/"
    pathnameBase: "/person/203876/items/"
    route: {caseSensitive: undefined, element: {…}, index: true, path: undefined, children: undefined}

Reproducible demo https://stackblitz.com/edit/github-1iyzlr?file=src%2FApp.tsx

Thus navigating to .. in my case, would pop the index page out of the match stack, and then take the user to that address. But that ends up being the link to the nesting "parent" page

[Huulivoide]

It seems that this is as designed
They have tests in place ensuring that to=".." navigates back to the same page in index route.

I guess that technically this is "correct" if the documentation says that .. traverses up by one "Route".

Tough I feel like the index routes should maybe be a special case to the rule.

[shulcsm]

This is REALLY annoying with index routes and used to work in beta.

Imagine scenario

<Route path=":id/">
  <Route index element={<Link to="../../sibling" />} />
  ....
</Route>

[Romcol]

I have also experienced the bug. This is also a breaking change coming from reach router. It should be fixed or specified in the doc :)

[JaffParker]

I experience this problem and it makes kind of no sense how these work. I actually expect it to go up a route in the tree as opposed to just removing one segment (although in this particular instance it's the same). Here are my routes:

<Route path="/settings">
  <Route index element={<SettingsRoute />} />
  <Route
    path="account"
    element={<SettingsRoute page="account" />}
  />
  <Route path="team">
    <Route index element={<SettingsRoute page="team" />} />
    <Route
      path="create"
      element={<CreateUserRoute />}
    />
    <Route path=":id">
      <Route index element={<EditUserRoute />} />
      <Route
        path="history"
        element={<UserActivityHistoryRoute />}
      />
    </Route>
  </Route>
</Route>

Here's the list of routes I have with the desired to=".." behavior:

/settings -> nothing, it's the root
/settings/account -> go back to /settings, works
/settings/team -> go back to /settings, does not work since the index' parent route is path="team", which is silly
/settings/team/create -> go back to /settings/team, works
/settings/team/:id -> go back to /settings/team, does not work since the index' parent route is path=":id", again silly
/settings/team/:id/history -> go back to /settings/team/:id, works

So the silly behavior comes from how the index routes are handled - they're treated as children of the parent route instead of being treated as the parent route itself.

Basically what I'm saying is, I think to=".." inside index routes should be treated as to="../.." for proper predictability. Otherwise, there's no workaround for this right now since I can't just render the element in the parent route, since that'll render it for all child routes; and I can't move everything a level up since that'll break navigation for the rest of the child routes.

Upd: I realize that's what everyone is saying, kinda got lost in the point while trying to make it. But the conclusion stands - index routes should ignore one parent in the tree when going back.