[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 [email protected], 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 [email protected] 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 [email protected] 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

[timneutkens]

Hey folks, wanted to share an update.

We really appreciate everyone’s feedback here. I spent today reading through every comment here and categorized them all in a document to further understand how we can improve.

We are evaluating the 30s client-side router cache behavior and ways to configure this value.

I’m going to post a new issue covering what the expected behavior is today, how you can configure and change those defaults, and then a set of questions you can answer that will help us determine the ideal expected behavior.

Thank you!

Ps: The reason the comments are marked outdated is just for keeping track of what has been read/tracked, they're not outdated, just had to pick one of the options.

[subvertallchris]

Thanks for getting involved, @timneutkens! This surely made a lot of people very happy. Can you share the link to the new issue here when it’s ready?

[timneutkens]

Hey everyone, I spent most of today writing down the individual cases that were highlighted in the feedback. I'm about halfway through the topics currently, expecting to wrap that part up on Monday.

I'll definitely share the new issue here when it's opened 👍

[timneutkens]

Spent all of yesterday on this still, close to finishing up the writeup, needs a review from @sebmarkbage later today.

Please be patient, I'm working on it, demanding an update is not constructive.

[timneutkens]

Hey everyone, thanks for your patience, took me quite a bit of time to write down all these behaviors but I think it will be helpful to start with a shared understanding of what the current behaviors are and how you can affect them using mutations.

Here is the new discussion, which includes a thorough explanation of mutations and other parts that relate to mutations, including how partial rendering works under the hood and expectations around back/forward navigations as well as how to achieve useSWR / react-query like behavior. At the end of the post are a couple of questions around the desired behavior from this issue around reducing the 30 seconds to zero.

I kindly request that you first read the entire post before posting a comment, this is to avoid misconceptions about how the router functions in particular cases, which should help with writing a constructive reply on the discussion:

The discussion

[timneutkens]

I'm going to close / lock this issue in favor of the posted discussion in order to ensure that everyone reads that explanation + questions so that we can resolve it there 👍