Why we use unstable_noStore in chapter8 and use revalidatePath in chapter12?

[kaworuist]

First, what are the differences between these two methods?
In Chapter 8, we used unstable_noStore to mark the fetchFilteredInvoices method for dynamically fetching data. Later in Chapter 12, we used revalidatePath to forcefully clear the cache for real-time data retrieval. In my understanding, both of these methods aim to ensure that /dashboard/invoices renders the latest data. What are the differences between these two approaches?

Second, when I attempted to remove these two cache handling methods, I noticed that the application still fetched the latest data without any apparent change in behavior. Is this behavior as expected?

[don-esteban]

Not sure, if I can explain it to you. But let's try. Disclaimer: I'm on a learning journey myself!

unstable_noStore will make the components render dynamically.

Chapter 8:

You can use a Next.js API called unstable_noStore inside your Server Components or data fetching functions to opt out of static rendering....

You switch your component from static rendering (default) to dynamic rendering. You could do this for whole pages or layouts with export const dynamic = 'force-dynamic'. See: https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamic

Try this. Build and start the local production server with next build; next start. Don't try in dev mode. Dev mode always loads pages dynamic. Add and remove noStore(). Now you should see the difference. Right?

revalidatePath revalidates the router cache if the path is next visited. In The tutorial you see:

revalidatePath('/dashboard/invoices');
redirect('/dashboard/invoices');

That means, revalidate this path and visit this path. This ensures that users see an updated page and not the cached version. Play around in dev and production mode. But keep in mind. In dev mode, all pages are dynamic.

I hope, this helps.

[kaworuist]

@don-esteban Thank you for reply. But I still confused. In the development environment, are all pages completely dynamic? Also, based on your suggestion, I tested the next build and next start(with noStore in fetchFilteredInvoices), but the behavior is also peculiar. By default, it does not cache results and instead makes a fresh request. However, after refreshing the page, it caches the results. After some time, it reverts to making fresh requests.

[don-esteban]

Hi @kaworuist, yes, me too :-). But, I think, it's a feature. We find answers here: https://nextjs.org/docs/app/building-your-application/caching

If you remove noStore() you get the default Full Route Cache behavior. That means Static Rendering (Static Site Generation). With noStore() in place, you get Dynamic Rendering. The Server renders pages/components at request time. This is what you see in your "movie". But, wait...

... there is another cache. The Router Cache which is duration-driven. Dynamically Rendered routes are cached for 30 seconds.

Probably it is, what you observe. Right? You visit the page (not cached). You reload the page (not cached). You revisit the page (cached). You revisit the page after 30 seconds (not cached).

I see plenty of complaints and confusion around caching. Most likely, we will see more resources, patterns, and information and possibly additional functionality for fine-controlling cache behavior. For a deep dive, see this discussion: vercel/next.js#54075

[kaworuist]

@don-esteban Thanks, I spent some time to read the next.js cache document and the discussion you pinned. I'm getting more familiar with next.js handling of caching, but at the same time, I think they don't handle the default behavior properly, and there are too many caching mechanisms and APIs that make the handling very complicated, and I can only hope that the handling will become more friendly in the future

[leerob]

#764