fix(react-router): fix useSearchParams when used together w/ useBlocker

[yuhwan-park]

Issue Overview

1. When passing the original searchParams to nextInit, if the nextInit implementation modifies properties using methods like delete() or add(). the internal property values of searchParams change before the navigate function executes.
2. When used together with the useBlocker hook, this can lead to searchParams values that don't match with location.search (which is a dependency).

Solution

• Modified to create a new URLSearchParams instance that points to a different memory address than searchParams. This ensures that even if searchParams values are modified in the nextInit function, the searchParams within the hook remains unchanged.

I have confirmed that issue #12256 has been resolved by implementing the exact solution specified in the issue description.

closes: #12256 #12188

[changeset-bot]

⚠️ No Changeset found

Latest commit: 189ae25

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[remix-cla-bot]

Hi @yuhwan-park,

Welcome, and thank you for contributing to React Router!

Before we consider your pull request, we ask that you sign our Contributor License Agreement (CLA). We require this only once.

You may review the CLA and sign it by adding your name to contributors.yml.

Once the CLA is signed, the CLA Signed label will be added to the pull request.

If you have already signed the CLA and received this response in error, or if you have any questions, please contact us at [email protected].

Thanks!

- The Remix team

[remix-cla-bot]

Thank you for signing the Contributor License Agreement. Let's get this merged! 🥳

[yuhwan-park]

Hi Team! I'd love to hear your thoughts on my solution approach.

I believe this issue could come up quite frequently in real-world scenarios. It's pretty common to implement navigation blocking using query strings and useBlocker (e.g., ?mode=edit).

From my perspective, the changes I proposed don't affect the React rendering cycle or useSearchParams hook original behavior at all - they just fix a bug related to object reference equality. However, I want to make sure this approach isn't too aggressive or radical. What do you think?

[MichaelDeBoey]

Not sure if we want to add the URLSearchParams call here or in getSearchParamsForLocation 🤔

CC/ @brophdawg11

[yuhwan-park]

The getSearchParamsForLocation function already returns a new URLSearchParams object each time.
Here's what's happening in the flow that causes the bug:

1. setSearchParams executes (this is where searchParams changes)

setSearchParams((prev) => {
    prev.set("mode", "edit");
    return prev;
  })

3. router.navigate() runs
4. It gets blocked by useBlocker
5. Even though the location.pathname hasn't changed, the searchParams returned by useSearchParams remains in the modified state

Because of this flow, I think we need to create a deep copy of the URLSearchParams before passing it to the nextInit function - regardless of how nextInit is implemented - to ensure it behaves as intended.