Page-level "revalidatePath"

[00:00 - 00:06] We've seen that static rendering is quite performant. It really resist the load test that I've been running on my computer.

[00:07 - 00:16] And it makes sense for e-commerce because the project list is the same for all users of the eCommerce. So it would make no sense to rerender it on every request.

[00:17 - 00:28] The result will always be the same unless the e-commerce owner adds a new product. And the great thing with Next is that we now have APIs to do exactly that.

[00:29 - 00:46] Update the static page whenever a Server Action has been run, or an API call or anything that can update the data in the database. We are going to discover two APIs, revalidatePath and revalidateTag.

[00:47 - 01:06] I would say that revalidatePath, the first one that we are going to discover, is the most intuitive and easy to use and it's perfectly fine. revalidateTag is a bit more advanced, is a bit newer, it's different from the way we've been thinking about Next.js application so far.

[01:07 - 01:12] And it's using more recent APIs. It's a bit more complicated but a bit more powerful too.

[01:13 - 01:17] So we will see that in the next lesson. So I'm back on my product creation form.

[01:18 - 01:25] I see that it triggers a createProduct action. And if I check the code, it update the database.

[01:26 - 01:34] But then what? And I've actually commented some code that is interesting, which runs a function named revalidatePath.

[01:35 - 01:43] I will uncomment just this part. There is an alternative with revalidateTag but we will see that in the next lesson.

[01:44 - 01:52] And it's actually very intuitive what it does. It revalidates the homepage and it revalidates the project page.

[01:53 - 02:07] Why this term? Revalidating. The idea is that you should think about static rendering like caching pages, caching the HTML generated for pages.

[02:08 - 02:20] It's not exactly HTML with React Server Component, it can be a JSON payload that represents the data that are rendered by the component. Because React Server Components again have to integrate with client-side code.

[02:21 - 02:33] So it's always a bit more complicated than what we should think conceptually. But the broad picture is that it caches the page at built-time.

[02:34 - 02:56] And Revalidation is saying, "Yes, but this built-time content, it's not up to date anymore, it's not valid anymore, we need to revalidate." And the idea is that this will trigger what we call the stale-while-revalidate strategy, meaning that the old content will still be served to users while next computes a new version on the future request.

[02:57 - 03:04] And the new content will be available very quickly. There is no interruption and the page is basically updated in the background.

[03:05 - 03:09] So we can easily test that. Let me open the terminal back.

[03:10 - 03:15] We are going to close the load test. We need to rebuild the application because I was running in production.

[03:16 - 03:26] Small note, if you run Next.js in development, you won't be really able to test static rendering. Because in development every request will still rerender the page.

[03:27 - 03:35] For the reason is that it would be very annoying to have to refresh the page every time during development. My server is running.

[03:36 - 03:46] Now I can check the project page. Since I've rebuilt the page, I can see the product I've added earlier in the previous lesson.

[03:47 - 03:59] So let's add another one. $42... save the change, see the project list, and now it's almost immediately up to date.

[04:00 - 04:04] I see my other product. Yet the page is still static.

[04:05 - 04:14] I didn't have to make it dynamic for each request. There is no new rerender of the page after the compilation, after the revalid- ation.

[04:15 - 04:31] If I check the server logs, I will see that during development, if I can get them, we will see five products, most probably, given that I see six products now. So okay, the product list has been rendered with five products.

[04:32 - 04:41] I've just added some logs when rendering to be able to tell when it's rerendered. Then I add my new product.

[04:42 - 04:47] And then I see it's rendered with six products. It's rendering multiple times.

[04:48 - 05:25] Again, this is noise due to most probably, I think, from React strict mode I've invalidated not one, but two paths, given that the project list is here on the products page, but also here on the home page. So I have to invalidate both paths.

[05:26 - 05:35] If I invalidate only the home, then only the home will have the up-to-date products . At this point, you may think this might become annoying when I have a lot of pages.

[05:36 - 05:43] And the next lesson about revalidateTag is exactly about that. revalidateTag will allow us to invalidate the data rather than the pages.

[05:44 - 05:54] Again, the page is still considered static. Static in a sense that may be a bit different from exporting HTML that is dead and never changes.

[05:55 - 06:12] It's not that static in a sense that we still have a running server that is able to rerender the page at runtime. We see that there has been rendering after I started the server, a runtime render, a bit like dynamic.

[06:13 - 06:20] So you have to have a server that is running enabled to rerender the page. You can't have just dead HTML.

[06:21 - 06:26] Otherwise, this is what we call in Next a static export. In Next, we will talk about exporting the application.

[06:27 - 06:41] In other technologies, we will talk about maybe Single-Page Applications or in some of the frameworks, this is actually what they call static. You get the idea, the idea is that I still need the server running.

[06:42 - 06:55] I will do a rerender at runtime, but not for every request. And so we are still in the static world, but we allow revalidating some pages without rebuilding the whole application.

[06:56 - 07:05] So that's already a good progress because we can have static and up-to-date data. We don't have stale rendering, we have static rendering.