We configured the Home and Reviews pages
to "revalidate" every 30 seconds,
so if we publish a new entry in the CMS
the pages will display the new data,
albeit after a short interval.
Now, there's another way to enable
Background Revalidation:
instead of configuring it at the page level,
we can specify a similar option
when making a "fetch" request,
because, after all, it's the data
we fetch that can change,
making it necessary to re-render the page.
So, let's try this other approach,
by removing "revalidate" from the page.
And we'll need to do the same in the ReviewsPage.
As for the individual ReviewPage,
we didn't set "revalidate" here,
but this also fetches data from the CMS,
by calling "getReview",
that in turn uses "fetchReviews".
In the end all CMS requests
are made by this function.
So to keep things simple we'll
configure revalidation here.
"fetch" accepts an optional second argument
that's an object when we can set request options.
Most of these settings are standard,
like "cache" for example.
If we set this to "no-store",
this will tell Next.js not to save
any responses to the cache.
Let me show you this in action,
since disabling the fetch
cacheÂ can also be useful.
Let's do a new build,
and I didn't delete the ".next" folder because
we disabled the fetch cache anyway.
You can see that by setting "cache" to "no-store"
Next.js treats our Home and
Reviews pages as dynamic.
If you remember, the "dynamic"
behavior defaults to "auto",
which means that Next.js decides automatically
based on what our page code does.
Since these pages call "fetch" with
"cache" set to "no-store",
Next.js figured out that these pages
need to be rendered dynamically,
in order to display the latest data.
So, setting "cache" to "no-store"
has a similar effect
to configuring our pages with "force-dynamic".
Now, the "reviews/[slug]" route still
shows as statically generated,
which is a bit misleading.
The build did generate all
the existing review pages,
because we have a "generateStaticParams" function,
but since we disabled the "fetch" cache
it should refetch the data at every request.
This build output is a bit of a simplification.
It doesn't always take all
the details into account.
Anyway, let's go and start the server
and see how our application works in practice.
You can see that it rendered
the HomePage at runtime,
along with all the linked pages.
And if I clear the logs, and reload,
the server renders all the pages again.
Every time we request the page, it's regenerated.
It will be the same for the Reviews page,
and each individual review as well.
So all the pages are effectively "dynamic",
just like when we configured
them with "force-dynamic".
But in this case we set "cache" to
"no-store" in the "fetch" options,
and the result is similar,
because Next.js automatically realized that
if "fetch" returns a new response every time
then the server also needs to generate
each page dynamically,
in order to show the latest data.
Now, let's see how we can use
"revalidation" instead.
We can pass some Next.js-specific
options to "fetch".
That's because Next.js extends
the standard "fetch" function
adding its own caching functionality
on the server.
Here we can set the "revalidate" option,
passing a time interval, like 30 seconds.
So, this works like when configuring
it at the page level.
Let's give it a try,
by making another production build,
which as usual will take a few seconds.
All routes are shown as static,
because they have been generated during the build,
but they should also use revalidation.
Initially the server returns the static pages.
But let's go and change some data in the CMS.
I'll just add "update 1" to this title.
And if we go back to our application,
it will not update immediately,
but if we keep reloading,
at some point the old page will expire,
and you can see that the server
renders a new version,
including all the linked pages.
But in the browser we still see "Subnautica 2",
because, as I explained in the previous video,
the first request that triggers revalidation
still receives the old page.
But if we reload again,
this time we see the new title.
The Reviews page should also be updated.
And the "subnautica-2" page as well.
In the previous video we didn't configure
the ReviewPage to revalidate,
because we assumed we only wanted
to publish new reviews,
but by configuring revalidation
for all fetch requests,
it also applies to this page.
Apart from that, everything works
effectively in the same way
as when we configured revalidation
at the page level.
So, how do you decide which approach to use?
In practice, if you do use "fetch"
in your application
then it's more convenient to set
the "revalidate" option here.
This also provides more flexibility,
because you could set a different interval
on different "fetch" calls,
in case you make multiple API requests
to render the same page.
But not all applications use "fetch".
If you load data from a database for example,
then you'll have to configure revalidation
at the page level instead.