Strip basename from location provided to getKey

[brophdawg11]

Fixes issue raised in #9565 (reply in thread)

We were calling getKey inconsistently. From the usePageHide hook it was the useLocation value (not including basename) but from inside the router it was the router.state.location (including basename). Now it's always the user-land version without the basename

[changeset-bot]

🦋 Changeset detected

Latest commit: 797fcb1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@remix-run/router	Patch
react-router	Patch
react-router-dom	Patch
react-router-dom-v5-compat	Patch
react-router-native	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jrnail23]

Thanks for jumping on this so quickly, @brophdawg11. Any reason stripping basename isn't the useLocation behavior all the time? It seems like it should be consistent everywhere, but I've had to strip it myself in another case where I was capturing a location to use for a "back" button in my UI (similar to what I've talked about in the Events discussion).

[brophdawg11]

It is the default - you should never be getting a path back with the basename from useLocation. If you are, a reproduction would be great to see why...

[brophdawg11]

Note to self: see about moving this to the RR layer since that's where the basename stripping should happen to stay consistent

[jrnail23]

I'll see what I can do to get you a repro, but the fact that useLocation (in at least some cases) returns pathname with the basename is the basis for the issue this PR is addressing, right?

[brophdawg11]

@jrnail23 Not quite. The location kept inside the @remix-run/router, which is basically a mirror of window.location, contains the basename (to match window.location) and that is what is being sent, unstripped, to getKey.

[jrnail23]

Okay yeah, my bad @brophdawg11, I had it backwards.

[jrnail23]

As a suggestion, distinct TypeScript types for internal location vs. user location may be helpful to ensure the correct kind of location is used in the correct places. Specifically (and I know this may be something of a controversial topic in TS), nominal/branded/opaque types, particularly in your internal-only stuff go a long way toward this goal.

I use ts-essentials' Opaque type pretty extensively in my own apps, and I've been really happy with it.

[jrnail23]

It turns out that when I mentioned that I had to stripBasename myself was in an unstable_useBlocker callback -- those locations are not stripped.

[brophdawg11]

unstable_useBlocker probably has the same bug as getKey - I'll check that one out too

[github-actions]

🤖 Hello there,

We just published version 6.14.0-pre.0 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 6.14.0 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!