[Bug] next/link is not calling the server for subsequent navigations on dynamic routes

[Fredkiss3]

Describe the feature you'd like to request

In the documentation it is said that the conditions for hard navigation are :

• when navigating between dynamic segments
• When navigating between two different group layouts (ex: from (groupA)/layout to (groupB)/layout )

I'd like to suggest also adding hard navigation for segments marked with dynamic='force-dynamic' or when using dynamic functions and even when using fetch with cache: 'no-store'.

In the docs you said that using these configurations is like using getServerSideProps() in the pages directory, but it does not behave the same between navigations which is quite confusing.

Use cases for this feature could be these :

• this app that only store pokemon data in cookies (Live here and source here)
• this simple case for an app that generate a random number each time : ckblitz.com/edit/nextjs-sxijav?file=package.json,app%2Fnested%2Fpage.tsx

Describe the solution you'd like

The solution i propose is to consider hard navigation for these cases :

• When navigating to a page marked with dynamic='force-dynamic', next should always do a hard navigation

• When navigating to a page using dynamic functions headers() and cookies(), next should always do a hard navigation

• When navigating to a page using fetch with cache: 'no-store', next should always do a hard navigation, or at least next should always refetch the data

• When navigating to a page using either fetch with next: { revalidate: n_seconds } or export const revalidate = n_seconds, next should only do hard navigation when the n_seconds has elapsed.

The last two could be tricky and if it is not ideal, at least add a paragraph in the doc explaining why it is not possible and maybe recommending the first two approaches.

Describe alternatives you've considered

Updates

• In next@13.3.1, using a <Link prefetch={false} /> seems to fix the problem : https://stackblitz.com/edit/vercel-next-js-n1tqpr?file=app%2Flayout.tsx
  . But it disables link prefetching and result in slower navigations.

• As of next@13.4.0 the client side cache has been reworked, dynamic pages are now cached in the client with a timer of 30 seconds, so every 30 seconds your server is recalled, with one catch : this only apply if you navigates to a different page after that time, if you do very fast back & forth to the same page, the timer will reset and only wait for another 30 seconds. Disabling prefetch does not solve the problem anymore, it disables prefetching, but once the page has been navigated to, the rules of 30 seconds still applies. If you want the old behaviour, you'd have to downgrade to next@13.3.1 for now, You will loose support for Server Actions & revalidate primitives though, Or you can also not use the Link component and use regular a tags if you still want the new features of Next.

However there are things in the work for both allowing prefetching on hover (with <Link>) and allowing for setting the stale time on the client side cache. You can read in the PR about the client side rework :

Follow ups

• we may add another API to control the cache TTL at the page level
• a way to opt-in for prefetch on hover even with prefetch={false}

This would allow for setting a pageTTL = 0 for calling the server on each & every navigation to always have fresh data.

_NEXT-1352

[Fredkiss3]

Any news yet about this feature ?

[zenflow]

I believe this proposal is to fix these issues:

• App Dir is caching renders even with "dynamic" set to "force-dynamic" #42546
• Dynamic data fetching not working #43879

I am strongly in favor changing/fixing the rules of when soft vs hard navigation happens, to support dynamic data on pages that have no dynamic segments. You can see from the docs that soft navigation (i.e. client side cache) will always be used in this case (https://beta.nextjs.org/docs/routing/linking-and-navigating#conditions-for-soft-navigation) and there's no way to override this. There's effectively no way to bust the client side cache for these pages except a manual router.refresh().

At the same time, I'm against the exact proposal. I'd prefer to keep rules for client-side caching (hard vs soft navigation) separate/independent from rules for server-side caching (dynamic='force-dynamic', cache: 'no-store', etc). There seems to be some confusion around the fact that we are dealing with two separate caches and the proposed solution would definitely add to that, as well as make it more difficult learn and reason about how next.js is supposed to behave in whatever situation.

@leerob Can we have an option like export const navigation = 'hard' to force hard navigation on pages where it's needed?

[Fredkiss3]

For sure, conceptually there are two caches, but to the developer who doesn’t understand NextJs RSC that deep it does not seem like it. I’ve read the docs more than 3 or 4 times, yet I didn’t see any mention of the two caches as separate, there is dynamic rendering, dynamic segments and dynamic functions which are very confusing. And for the longest time I thought they were all equivalent or similar.

As for adding a new option, this would confuse people more I think. Maybe it is the best for performance, but DX wise it is not ideal. And more, it would be difficult to wrap our head around how it would play with the rest of options (dynamic rendering, dynamic segments & functions).

But IMO, when NextJs says in their doc that export const dynamic="force-dynamic" behaves like gSSP in pages directory I expect it to behave like it and rerender on page navigation, if not then the docs should precise that caveat and give us a way to make it behave exactly like gSSP.

[zenflow]

True that adding a new option might add some confusion in the sense that it's more cognitive overhead (more to learn from docs and think about for every page) and I think we definitely already have enough of that with app/ dir, so I definitely want to keep it as simple as possible. I have given it some more thought..

So the Conditions for Soft Navigation (new in app/ dir) is causing our problem, inaccurately trying to guess whether hard or soft nav is appropriate:

On navigation, Next.js will use soft navigation if the route you are navigating to has been prefetched, and either doesn't include dynamic segments or has the same dynamic parameters as the current route.

For example, ...

Why do these conditions even involve whether the page has dynamic segments or not? Does it make sense?

• (our problem) For pages without dynamic segments, we may or may not want to skip frontend cache, since these pages might also have dynamic data which we want/need to be fresh.
• (also) For pages with dynamic segments, we may or may not want to have frontend cache, since these pages might also have data which we don't need to be so fresh, and we can take advantage of client side cache to reduce requests to server.

The ideal solution IMO:

• soft vs hard navigation applied to pages regardless of dynamic segments or their params
• static pages always use soft navigation (already the case i looks like, judging by docs)
• dynamic pages default to hard navigation & can opt in to using soft navigation (i.e. client side cache) via export const navigation = 'soft' or some option like that

What do you think? There would be a new option, but you wouldn't have to use it or worry about it unless you wanted to optimize performance & reduce requests to server for a dynamic route, with using a feature that's new in app/ dir.

[Fredkiss3]

I’m all in on your proposition 👍

[njarraud]

The current state with hard/soft navigation as well as prefetch is still very buggy and I would love seeing the improvements stated above.

• prefetch={false} currently fully reloads the page (with loss of state that goes with). The SSR components also run twice (navigate from homepage to page1 in example)
• In the documentation it is stated that soft navigation occurs if the route you are navigating to has been prefetched, and either doesn't include dynamic segments or has the same dynamic parameters as the current route. It is actually not fully true. Navigating from page1 or page2 to page1/123will actually perform a hard navigation but from / to page1/123 does not (soft navigation).

Link to my simple example https://codesandbox.io/p/sandbox/nextjsappdirnav-d6clzo
I console log on the server when the SSR components are rendered.

• page 1 links are prefetch={false}

Currently I cannot find a solution to force re-rendering SSR pages (hard navigation) as prefetch false is broken.

[Fredkiss3]

@njarraud I don't remember where i've seen this but someone suggested to create a client component solely for the sake of refreshing the page, something like this :

// components/refresh-page
'use client';

import { useRouter } from 'next/navigation';

export function RefreshPage() {
  const router = useRouter();
  useEffect(() => {
      router.refresh();
  }, []);
  return null;
}

// page.tsx

export default function Page() {
  return (
   <>
      <RefreshPage />
       {/*... rest of your server-component code*/}
   </>
 )
}

But to be honest with you this workaround is not ideal.

[njarraud]

Thanks. It kinda does the trick-ish as a quick and dirty temporary "fix".
It renders the page twice on first page load (production) and multiple times in dev. Just have to cross my fingers for a proper fix from the next team in the future.

[hubertlepicki]

@Fredkiss3 thanks for the code, you saved the day! But indeed, a solution like @zenflow suggests would be ideal.

To add to tiscussion, I think this is only a problem if a link leading to such dynamic page is prefetching, which is unfortunately the default. The other workaround I found was to disable link prefetching, i.e. if I do:

<Link to="/random" prefetch={false}>Click me</Link>

the above does seem to not use the cache as my random page generation page returns a different number every time, but I also think the whole page reloads on link click as a result so that's suboptimal. I think this may be a separate bug, as the Link now behaves like a tag with no extra behavior added.

Another workaround I found is not to use the Link at all, but instead useRouter and do push(href) directly. I wrapped it in a simple component and have started using instead of Link when linking to dynamic pages, seems to work just fine without doing any caching or any prefetching.

'use client';

import { useRouter } from 'next/navigation';

export default function DynamicLink({href, children}) {
  const router = useRouter();

  return(
    <a href={href} onClick={(e) => {e.preventDefault(); router.push(href)}}>{children}</a>
  );
}

I think this is the best solution I found so far.

[Fredkiss3]

I think @hubertlepicki your solution is just better 🤩, and i think i will use that for now until this issue is fixed.
To add to this, i modified the code to be more complete with typescript :

'use client';

import { useRouter } from 'next/navigation';
import { forwardRef } from 'react';

const DynamicLink = forwardRef<
  HTMLAnchorElement,
  Omit<React.HTMLProps<HTMLAnchorElement>, 'ref'>
>(({ href, children, ...props }, ref) => {
  const router = useRouter();

  return (
    <a
      {...props}
      ref={ref}
      href={href}
      onClick={(e) => {
        e.preventDefault();
        router.push(href);
      }}
    >
      {children}
    </a>
  );
});

export default DynamicLink;

[hubertlepicki]

@Fredkiss3 ah yes and passing the props to the a tag, indeed that makes sense!

[Fredkiss3]

Was experimenting with this behavior and it seems that you can force next to always do a hard navigation if you pass a querystring to the link component.

Updated the example by just adding a querystring, and it seems to work : https://stackblitz.com/edit/nextjs-smotka?file=app%2Fpage.tsx,app%2Fnested%2Fpage.tsx

This have the advantage of the page being prefetched on the first render, and always refetched on every navigation.

One other thing is noticed is that without this hack, when the page has been prefetched, it will load on the first navigation and next will scroll to the top of the page, but on subsequent navigations it doesn't. When you introduce this hack, it will always scroll to the top [video example down here].

Enregistrement.de.l.ecran.2023-01-11.a.22.39.09.mov

Warning
THIS IS DEFINITELY A BUG