Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Page won't rerender when initial searchparam is removed #65030

Closed
LuiGeeDev opened this issue Apr 25, 2024 · 4 comments · Fixed by #65977
Closed

Page won't rerender when initial searchparam is removed #65030

LuiGeeDev opened this issue Apr 25, 2024 · 4 comments · Fixed by #65977
Labels
bug Issue was opened via the bug report template. locked

Comments

@LuiGeeDev
Copy link
Contributor

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/admiring-bush-58lfx2

To Reproduce

  1. Start the application.
  2. Try clicking 'Change Query' button.
  3. It will change query and the page will show query: newQuery.
  4. As query stays on browser's url, refresh the browser.
  5. Try clicking the button again.
  6. URL changes, but page won't show query removed.

Current vs. Expected behavior

Current: Page won't rerender when the initial query has removed. (It works when it is changed)
Expected: Page render again when the initial query has removed, like when it changed.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 14.2.0-canary.9 // There is a newer canary version (14.3.0-canary.22) available, please upgrade! 
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

No response

@LuiGeeDev LuiGeeDev added the bug Issue was opened via the bug report template. label Apr 25, 2024
@ezengaston
Copy link

ezengaston commented Apr 25, 2024

Downgrading to version 14.1.4 solves the problem, indicating that the bug was introduced in version 14.2.0.

@LuiGeeDev
Copy link
Contributor Author

LuiGeeDev commented May 3, 2024

Maybe some workaround who doesn't want to downgrade.

const params = new URLSearchParams(searchParams.toString());
params.delete('your-param'); // this doesn't work now with bug.
params.set('your-param', ''); // this will still work.

const newRoute = `${pathname}?${params.toString()}`;

router.replace(newRoute);

@icyJoseph
Copy link
Contributor

We are experiencing this as well. Has there been any release notes, and such that would indicate, that this is the expected behavior?

ztanner added a commit that referenced this issue May 20, 2024
…rch params (#65977)

cc @icyJoseph @ztanner

NOTE: The canary release
[`v14.1.1-canary.51`](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.51)
and below work as expected.

### Why?

Introduced from #61535, the initial prefetch cache is set based on the
`location.pathname`.
When a page is loaded WITH the search param, the cache key does not
contain information of the search param.

The issue is when on a dynamic page reading the `searchParams` value,
the value doesn't change if navigated as:

```
/?q=foo --> /
```

The prefetch cache hits, not re-rendering, and the `searchParams` value
is not passed properly.

### How?

For the prefetch cache, add the `location.search` as well.

Since `createPrefetchCacheKey` uses
[`createHrefFromUrl`](https://github.com/vercel/next.js/blob/canary/packages/next/src/client/components/router-reducer/create-href-from-url.ts)
which includes `location.search`, I'm expecting the change won't affect
current cache key behavior.

Fixes #64170
Fixes #65030

---------

Co-authored-by: Zack Tanner <[email protected]>
Copy link
Contributor

github-actions bot commented Jun 5, 2024

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot added the locked label Jun 5, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 5, 2024
ztanner added a commit that referenced this issue Jul 9, 2024
…rch params (#65977)

cc @icyJoseph @ztanner

NOTE: The canary release
[`v14.1.1-canary.51`](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.51)
and below work as expected.

### Why?

Introduced from #61535, the initial prefetch cache is set based on the
`location.pathname`.
When a page is loaded WITH the search param, the cache key does not
contain information of the search param.

The issue is when on a dynamic page reading the `searchParams` value,
the value doesn't change if navigated as:

```
/?q=foo --> /
```

The prefetch cache hits, not re-rendering, and the `searchParams` value
is not passed properly.

### How?

For the prefetch cache, add the `location.search` as well.

Since `createPrefetchCacheKey` uses
[`createHrefFromUrl`](https://github.com/vercel/next.js/blob/canary/packages/next/src/client/components/router-reducer/create-href-from-url.ts)
which includes `location.search`, I'm expecting the change won't affect
current cache key behavior.

Fixes #64170
Fixes #65030

---------

Co-authored-by: Zack Tanner <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue was opened via the bug report template. locked
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants