#Caching

1 messages · Page 1 of 1 (latest)

fathom wagon
#

Here is how think of the cache the easy way.

You have two modes of rendering in Next.js. Static Rendering and Dynamic rendering.

Static Rendering: doesnt read user's request, only made to build once and forget about it. These pages are build and stored in Full Router Cache

Dynamic Rendering: does read user's request, they are rerendered every user requests. All functions and RSC gets rerun everytme users access to it.

Withing Dynamc Rendering, its easy for users to spam left and right by going back and forth navigations and trigger server-side data fetching and server-side RSC rendering. Thats 2 problem. Those 2 problem are solved by having Router Cache (aka client side cache) and Data Cache.

Data Cache solves server-side data fetching so that if users really do go back and forth navigation and there are no data chaged, why fetch them over and over? Just store the return a function in a Data Cache which is configurable and taggable.

Router Cache solves the rerendering of the whole page. If users really do go back and forth navigation and there are no visual changes, i.e users dont do mutations therefore no need to change any UI, why rerender them over and over? Just store the "rendered" page in a client-side router cache called the Router Cache

#

Ez

#

Oh and request memoization basically solves the problem of composability, not a direct effect to user experience.

In RSC you can nests components and its recommended for you to fetch the data where data is needed (context pattern) rather than prop drilling.

Request Memoization allows you to: under one render pass, only call a function once despite them being called multiple times in different places. Also known as deduplication

calm sky
#

Great explanation, thank you! Now, some things make more sense to me. However, I have a question: how can I deliberately decide which pages will be static and which will be dynamic?

fathom wagon
#

Here are some things to consider.

  • They are static by default until you deliberately use dynamic features
    Next.js tries to automatically decide this for you and this is what they think is better since last year May (Next13.4). Maybe it will change in the future lol

  • The staticity of a route is not decided per route segment but as a whole route.

If you have "force-static" in a /dashboard/layout.tsx, then all their route segment will be static.

If you have "force-static" in a /dashboard/page.tsx then only /dashboard will be static. /dashboard/something will follow whatever they are configured to be (i.e it can by dynamic).

#
  • as of now you can't tell which one is dynamic and statc at dev. You'd need to build your pages first to see which routes are dynamic and which routes are static.
calm sky
#

I'm understanding, thank you very much!

fathom wagon
#

Cache invalidation works in both statically rendered routes and dynamically rendered routes. So if you set your invalidations correctly and you set up your data fetching correctly, then ideally, having Next.js decide which route is dynamic and which one is static becomes natural