[Bug]: useResolvedPath breaking.

[chinfeng]

What version of React Router are you using?

6.20

Steps to Reproduce

Because of useResolvedPath is broken, now I am unable to deal with navigate inside the wildcard '/path/to/*' route ...

eg:

// route path is "/base/*"
const to = useResolvedPath('path/to');
const handle = () => navigate(to);

<Link to="path/to">path/to</Link>

Expected Behavior

It will always navigate to /base/path/to before useResolvedPath is broken.

Actual Behavior

It will navigate /base/path/to/path/to/path/to/... depends on my current path both navigate and <Link>.

[ilteoood]

I'm experiencing the same with Link and useNavigate.
Everything seems to be working fine with version 6.19.0

[birdofpreyru]

+1. useResolvedPath() is broken since v6.19.0, the issue persists in the latest v6.20.0, and it used to work fine in v6.18.0.

In my project I call useResolvedPath('*') when at the current location /some/path. Up to v6.18.0 it was resulting in

{
  "hash": "",
  "pathname": "/*",
  "search": ""
}

Since v6.19.0 it results in

{
  "hash": "",
  "pathname": "/some/path/*",
  "search": ""
}

Also, somehow, I haven't experienced any issues in my other project with fewer and simpler route structure. I guess #10983 is the primary suspect for the break.

[birdofpreyru]

Also, IMHO, alongside with #10579 this is the second critical, and easy to miss when upgrading dependencies, regression within ~5 months in what is supposed to be a quite straightforward and stable library. Not good.

[brophdawg11]

This is due to a bug fix that was included in 6.19.0 and called out in the release notes.

Relative path resolution without any leading . or .. is relative to the current location in the route hierarchy.

So if you are on a path /a/b/c and you resolve a path d/e via Link/navigate/useResolvedPath, the resulting resolved path should be /a/b/c/d/e since it is resolved from the current location.

Previously in splat routes, this was broken and was relative to the parent (if the splat was alone in the route path - path="*") or relative to only a portion of the current route path (path="parent/*"). This was incorrect and inconsistent with how relative routing works in React Router for static routes and dynamic param routes.

I put together small code sandbox to show the resulting consistency with the bug fix - https://codesandbox.io/p/sandbox/spring-resonance-kcgn6p?file=%2Fsrc%2Findex.js. If you set the react-router-dom version back to 6.18.0, you can see how the splat route is handled differently (and incorrectly) compared to other route types.

Another case that this shows itself (the original bug that was filed in Remix) is when using <Form action="."> on a splat route and the form does not submit to the current location but instead the parent location without the splat route which is also incorrect and results in a 405 error: https://codesandbox.io/p/sandbox/ecstatic-gagarin-fv76x7?file=%2Fsrc%2Findex.js

We apologize if your applications were relying on this buggy behavior. We take the stability of React Router seriously and did our best to call attention to this bug fix in the 6.19.0 release notes.

If you are using a splat route hierarchy such as <Route path="parent"><Route path="*"></Route>, then the best way to handle this is to add a .. to your path to make it resolve relative to the parent (without the splat value). If your splat is embedded in the path such as <Route path="parent/*"> and you want to "replace" the splat value, you can do that with a replacement such as:

let location = useLocation();
let params = useParams;
let newPath = location.pathname.replace(new RegExp(`${params["*"]}$`), 'new/path')

[chinfeng]

#11063

[fzaninotto]

Please reopen this. You've published a breaking change in a minor version.

We take the stability of React Router seriously

Closing this issue proves the contrary. You can't ignore the thousands of existing apps that your change have broken.

[ryanflorence]

I can't remember the details of it, so I'll need to dig in, but I'm pretty sure we have always needed to handle * differently and we probably introduced a new bug when fixing the other.

[dperetti]

You can't ignore the thousands of existing apps that your change have broken.

Yep, Remix app broken in prod 🙋.

[brophdawg11]

tl;dr; We're going to revert this fix and put it behind a future flag.

@mjackson, @ryanflorence and I just talked through this in detail and we do think that this is buggy behavior in 6.18.0 and earlier. However, it's obvious that a large number of folks were relying on this behavior so we are going to get this reverted and re-implement the fix behind a future flag so that you can opt-in at your convenience. We should have a patch release out this afternoon with the revert.

Along with the future flag PR (which I'll link to in this issue when ready), we'll include examples of where the original behavior is incorrect and how you can update your apps to work with the new behavior when you choose to opt-into the future flag.

Closing this issue proves the contrary. You can't ignore the thousands of existing apps that your change have broken.

Please keep in mind that we can't have any insight into how many folks were impacted by this fix at the time we closed this issue. Every bug fix is potentially a breaking change for somebody. As soon as we realized that this fix impacted a bunch of existing applications, we let y'all know we'd revisit the fix. So I would reiterate that we do take the stability of React Router seriously. That does not mean that there won't ever be bugs 🙂

[brophdawg11]

This fix has been reverted in v6.20.1

[fzaninotto]

Thanks a lot guys, you made the right decision. Apologies for the alarming tone, and let me take back my comment: you do care about your user base. Kudos!

[cduff]

@brophdawg11 I was hit by this and was just thinking about how I came to rely on this "buggy behavior".

I originally used Reach Router, as recommended by the React Router team at the time (before React Router v6).

I used "Embedded Routers" as per the example on this page: https://reach.tech/router/nesting.

I then migrated to React Router as recommended by the team.

Is my understanding correct that the Reach Router "Embedded Routers" example is now considered to have relied on buggy behavior?

Just trying to understand what the future direction might be and how it might impact my app.

Thanks for your time.

[bsides]

The funny part for me is that I never used relative paths before and started using in the (short-lived) reverted version. When I updated this week everything broke 😿

[brophdawg11]

This fix is now available behind the future.v7_relativeSplatPath flag in 6.21.0

[nicoqh]

The proposed solution to the problem wouldn't work:

<BrowserRouter>
  <Routes>
    <Route path="dashboard">
      <Route path="*" element={<Dashboard />} />
    </Route>
  </Routes>
</BrowserRouter>

Since the "dashboard" path doesn't have an element, it would render an <Outlet /> with null when you visit /dashboard.

You could either add another splat:

    <Route path="dashboard/*">
      <Route path="*" element={<Dashboard />} />
    </Route>

Or use an index route to make sure the Outlet isn't empty: "Index routes render in their parent route's outlet at the parent route's path."

    <Route path="dashboard">
      <Route index path="*" element={<Dashboard />} />
    </Route>

Splat routes are extremely useful and allows us to attach "mini apps" (features) that handle themselves, decide their own routing hierarchy, and don't care about naming conflicts with other parts of the app.

As the changelog says:

This makes code splitting and compartmentalizing your app really easy. You could render the Dashboard as its own independent app, or embed it into your large app without making any changes to it.

Want a messaging system? Just plug it in:
<Route path="/messages/*" element={<Messages />} />

[brophdawg11]

Oops - typo! I just pushed an update to add index so /dashboard also renders the <Dashboard> component.

Splat routes are extremely useful

We agree! The issue is that the prior approach introduced convenience at the cost of inconsistency:

• "." no longer means the current location (and sometimes even means the parent location)
• Paths resolve differently within a splat route versus a static or dynamic parameter route

future.v7_relativeSplatPath aims to resolve these inconsistencies

[birdofpreyru]

@brophdawg11 is it feasible to expose to components the root path where its immediate router assembly is mounted? I mean if a <Component> is essentially a <Router> with a bunch of paths, and it is mounted at some/path/* inside a parent component <Parent> IMHO it would be cool to have a hook that inside <Component> returns that some/path, thus helping to construct absolute paths with respect to that some/path mounting point? I guess, this would cover the main use case for which ppl used the old buggy behavior before (cause if there is a bunch of paths inside <Component> it might be way handier to use, for navigation, absolute links relative to its mounting point, rather than relative to the current location of each sub-component). If I am not missing anything, now it is only possible if that mounting point is passed down to <Component> via a dedicated prop?

[brophdawg11]

@birdofpreyru You could determine the parent path by stripping the splat value out of the location:

let location = useLocation();
let params = useParams();
let splatParentPath = params["*"]
  ? location.pathname.replace(params["*"], "")
  : null;

I don't know if we'd want to expose those types of internal router details via public API offhand, but feel free to open a proposal with some use-cases!