[Bug]: v6.4 behave different from v6.3 when the URL path has hash next to the param

[xdbobname]

What version of React Router are you using?

v6.4.0、 v6.4.1

Steps to Reproduce

• <Route path="/components/:id/" element={mainLayout} />
• <Link to="/comonents/title#Title-Title-label"}>
• const param = useParams();
• const {id} = param;

Expected Behavior

obviously the param 'id' should be title

Actual Behavior

the param 'id' is 'title#Title-Title-label'

[brophdawg11]

Can you provide your route definitions so we know what "id" param you're referring to? That way we can make sure we fully grasp your specific issue. Or even better, a reproduction of this issue in code sandbox?

[xdbobname]

emmm... I try a minify code in sandbox, but the bug didn't appear

[xdbobname]

https://codesandbox.io/s/gallant-kowalevski-45drzu?file=/src/App.js

[xdbobname]

okay, now the bug appear again, you just switch the version of react-router-dom to experience it.

[brophdawg11]

Interesting - so this is technically not a valid to value, but worked in 6.3 due to window.location fixing the issue for you. If you choose to specify the individual portions of a path (pathname/search/hash), then you shouldn't be mixing hash values in pathname:

<Link to={{ pathname: "/components/title#Title-Title-className" }}>

You should either be splitting it out:

<Link to={{ pathname: "/components/title", hash: "#Title-Title-className" }}>

Or passing the to value as a string, and we'll parse it internally:

<Link to="/components/title#Title-Title-className">

In 6.3, we sent the concatenated URL (to.pathname + to.search + to.hash) to pushState first and then re-read from window.location in react-router-dom which has by that point properly split out pathname and hash.

6.4 inverts that ordering since we're fetching data before updating the URL, so we're using the pathname you sent verbatim and it's not getting "fixed" by pushState.

I'll look into whether we want to sanitize these in 6.4, but I would recommend changing to pass a string value to Link instead of a split out path object.

[brophdawg11]

Instead of trying to sanitize these internally, we're going to detect these types of invalid paths and throw an error informing you to send in a correct path object or switch to a string (#9375)

[xdbobname]

okay, thanks!

[brophdawg11]

Just merged the linked PR - aiming to get a prerelease out today and a stable 6.4.2 next week 👍