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