[NEXT-1141] Next router / link not working when redirecting with new search params [Regression]

[mikebuilds]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:19:12 PDT 2022; root:xnu-8792.41.9~3/RELEASE_ARM64_T6020
    Binaries:
      Node: 18.15.0
      npm: 9.5.0
      Yarn: N/A
      pnpm: 8.0.0
    Relevant packages:
      next: 13.4.0
      eslint-config-next: 13.3.0
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/eloquent-https-5slx4d

To Reproduce

Navigate to the same URL with a new search param either via router.push() or the link component.

In the reproduction, wait for the initial page to load - then try and change to page 2, or 3, or use the search input.

Describe the Bug

The bug first appeared in 13.3.5-canary.2, prior versions works correctly.

Navigating to the same page with new search params no longer renders the loading.tsx.
Looking at the URL / network tab - it seems that the router does kick off the fetch for the new page, but then waits for the full body response before updating the URL, or rendering the loading page.

Expected Behavior

Prior to 13.3.5-canary.2, the behaviour was working correctly:

Navigating to the same page with new search params should show the loading.tsx, if the page is slow to fetch.

Video of this working previously:

TableFixed.mov

Which browser are you using? (if relevant)

N/A

How are you deploying your application? (if relevant)

N/A

_NEXT-1141

[mikebuilds]

For reference, I think this may be the issue commit: 25ba8a7 @feedthejim

Unsure if there is background here, but I can't think of why this could potentially be desired behaviour for any component using search params.

[feedthejim]

@mikebuilds can you perhaps share the code for the issue 2? It's hard to investigate because it could be a mistake in your code.

Looking into issue 1

[mikebuilds]

@feedthejim apologies, issue 2 is in fact a code issue - I changed some code when trying to debug issue 1, and accidentally introduced duplicate keys on the table rows.

Appreciate you looking into issue 1

[fprl]

Hello there,

Issue 1 is happening to me + other issue where next fetch don't take into account the cache and revalidate options in the fetch call and its only running the fetch again after 30s approx when navigating back to the route:

{
      cache: 'no-store',
      next: {
        revalidate: 0,
      },
}

PS: Found my problem and its probably related: #49300

[fprl]

Hey everyone, is there any update on this? loading.tsx is not rendering once searchParams has changed after using the example in the docs.

[psikoi]

What I've done to circumvent this issue is to use my own suspense boundary (with a key prop) instead of relying on the loading.tsx file's boundary.

In the Suspense's key prop I stringify the search params, that way it'll re-render (and fallback) whenever the search params change.

With this approach I was also able to exclude certain params from influencing the loading state, like the currently opened dialog.

example: https://github.com/wise-old-man/wise-old-man/blob/53bbe450f845d220895a46eee3f9da903f34674f/app-v2/src/app/names/page.tsx#L55

[fprl]

What I've done to circumvent this issue is to use my own suspense boundary (with a key prop) instead of relying on the loading.tsx file's boundary.

In the Suspense's key prop I stringify the search params, that way it'll re-render (and fallback) whenever the search params change.

With this approach I was also able to exclude certain params from influencing the loading state, like the currently opened dialog.

example: https://github.com/wise-old-man/wise-old-man/blob/53bbe450f845d220895a46eee3f9da903f34674f/app-v2/src/app/names/page.tsx#L55

I tried this, and it's only working for me in dev but not in prod:

import { Suspense } from 'react';

import { getHouses } from '@/utils/houses';

import Listings from '../components/listings';

type Props = {
  searchParams: {
    [key: string]: string;
  };
};

export default async function SearchPage({ searchParams }: Props) {
  const key = JSON.stringify(searchParams);
  const listingsPromise = getHouses(searchParams);

  return (
    <Suspense key={key} fallback={<Listings.Skeleton />}>
      {/* @ts-expect-error Async Server Component */}
      <Listings listingsPromise={listingsPromise} />
    </Suspense>
  );
}

PS: Keep in mind I'm sending the promise and not the result so that shouldn't be a problem.

[chillardinho]

@francoromanol have you tried to deploy it to somewhere other than vercel? I'm not sure but might be related to #51033.

there's also a similar problem mentioned in #42346 😭

[tantsur]

Guys, any news on that?

[alepacheco]

I had this issue today and had a difficult time finding a solution until i found this thread, using a key on the Suspense Element fixes it.

Let's get this issue resolved 🙏

[MelancholYA]

i added the JSON.stringify(searchParams) as a key on the suspense and it worked
not in production tho , it only works in dev env

[jaredgalanis]

Any updates on this?

Even with a key on Suspense I'm not seeing the loading template when updating query params and pushing into the router.

[jaredgalanis]

Any updates on this?

Even with a key on Suspense I'm not seeing the loading template when updating query params and pushing into the router.

I've actually realized that while this may not be expected behavior, I don't want to reload the entire fallback on query param changes. I'd rather use useTransition to provide a more subtle loading indicator per the React docs https://react.dev/reference/react/Suspense#preventing-unwanted-fallbacks.

[psikoi]

Any updates on this?
Even with a key on Suspense I'm not seeing the loading template when updating query params and pushing into the router.

I've actually realized that while this may not be expected behavior, I don't want to reload the entire fallback on query param changes. I'd rather use useTransition to provide a more subtle loading indicator per the React docs https://react.dev/reference/react/Suspense#preventing-unwanted-fallbacks.

Yes, this is something I have come to realize too, I now see the loading skeleton as the state for "no data yet", but if I'm updating the UI with new data (maybe due to some search or filters being changed in the URL), I prefer the user to still be able to see the previous results, with some more inline and subtle indication that the data is changing.

Here's an example in my app:

https://beta.wiseoldman.net/competitions

You'll see that as you first visit the page, there's a loading skeleton, but if you type in any search or select a filter, there's a subtle inline loading indicator that uses useTransition.

I found myself doing weird things like adding a key prop to the Suspense boundary, it was usually an indication that I was fighting the mental model of the app router because I thought that all loading states are equal. I do not believe they are, anymore.

[tonimercadante]

I'm doing a filter based on searchParams and I need to trigger the reload when the params change. Looking in the comments here it seems that in previous versions of Next it worked, I'm using version 14.0.3 and changing the params do not trigger the loading.tsx page.

[peiris]

I'm doing a filter based on searchParams and I need to trigger the reload when the params change. Looking in the comments here it seems that in previous versions of Next it worked, I'm using version 14.0.3 and changing the params do not trigger the loading.tsx page.

Same problem here

[nghyane]

I'm doing a filter based on searchParams and I need to trigger the reload when the params change. Looking in the comments here it seems that in previous versions of Next it worked, I'm using version 14.0.3 and changing the params do not trigger the loading.tsx page.

Same problem here :((

[judgemavi]

I experimented a little and found that using a regular anchor tag "a" instead of Link trigger loading.tsx every time.

I guess all assets are reloaded when using tag "a"

[MrLoh]

@psikoi is right that this is not a bug, but that the right solution is to use useTransition to show a more subtle localized loading state while query params are changing.

[abaksha-sc]

Hm, I even tried to generate page URLs like /report/page/X and this doesn't help. So seems like issue is not only with search params

[ymonye]

{ searchParams }: Props

Did you ever get this resolved? I'm also on Next 14 with the same issues

[LuizFernando991]

https://www.youtube.com/watch?v=UNEXbGJCTw8

In this video he demonstrates several techniques, the best for me is the one in minute 17