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]

🦋 Changeset detected

Latest commit: 6ae4889

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

This PR includes changesets to release 11 packages

Name	Type
react-router	Patch
@react-router/architect	Patch
@react-router/cloudflare	Patch
@react-router/dev	Patch
react-router-dom	Patch
@react-router/express	Patch
@react-router/node	Patch
@react-router/serve	Patch
@react-router/fs-routes	Patch
@react-router/remix-routes-option-adapter	Patch
create-react-router	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

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

[brophdawg11]

Thanks!

[github-actions]

🤖 Hello there,

We just published version 7.7.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 7.7.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!