I mentioned at the end of the last video
that fetching data on the client side
has the advantaged that
it ensures we're displaying the latest data
available in the CMS.
While if we fetch the data in "getStaticProps"
this may not be the case.
Because when we build our app for production
all our pages will be statically generated,
including their static props.
Let's see that in action
by creating a production build of our app.
If we look at the build output,
we can see our two different "index" pages here.
"index-1" has a filled circle next to it
because it uses "getStaticProps".
While "index-2" has an empty circle
because it uses no initial props.
But that's actually not
the most interesting difference between the two.
Let's run the app in production mode,
with "npm start".
And, let me clear the logs,
so we can easily see any new messages.
If we reload "index-2"
this will display the list of products.
And if we load "index-1",
this shows exactly the same list.
Even though the data is loaded differently,
the end result is the same.
But what happens if we now go and
update the data in the CMS?
For example we could edit the first product,
and change the title to say
"Aloe Vera - New!"
Let's click the "Save" button
to apply the change.
And if we now reload our "index-1" page,
nothing changes.
"index-1" uses "getStaticProps",
so the page is statically generated at build time,
including the list of products.
This means that we can refresh this page
as many times as we like,
but it's always going to be the same.
By contrast if we load "index-2",
this fetches the data on the client side,
so it re-requests the data from the CMS
every time we load this page.
And in fact you can see that in this case
the first product shows the new title.
So, does that mean that
if we want our website to display
up to date content from the CMS
we need to fetch the data on the client side?
That would be a shame,
because we've seen that the server side approach
has quite a few advantages.
Thankfully with Next.js
there are ways to update the data
even with the server side approach.
Next.js has a feature called
"Incremental Static Regeneration",
that we can use exactly for this purpose.
Let's see how this works in practice.
It's actually pretty simple.
Now, this also means that
there's more than one way to fetch data
on the server side.
So I'm going to rename
what we called "Option 1"
to "Option 1a".
And then I'm going to create
another variant of this page,
that we can label as "Option 1b".
So "Option 1b" will still be about
fetching the data on the server side,
but in this case we'll be using
"Incremental Static Regeneration".
Ok. Now, "Incremental Static Regeneration"
is quite a mouthful,
but in practice it means
just adding an option to the object
returned by "getStaticProps".
In addition to the "props",
here we can set a property called "revalidate".
And the value we pass here
is a number of seconds.
For example, if we set it to "60"
that means 60 seconds,
which is of course one minute.
And if we set it to 5 times 60,
that will be 5 minutes.
Now, what this "revalidate" value means
is how long are these props valid for.
If we set it to 5 minutes,
it means that these props values will
expire after 5 minutes,
so Next.js will call "getStaticProps"
every 5 minutes to get new "props" values.
Now, what I just said
is a bit of a simplification, in that
it's not like Next.js uses a timer
to call "getStaticProps" exactly every 5 minutes,
Next.js will only call "getStaticProps"
if the server receives a request for this page,
and the previous props have expired.
Anyway, let me show you this in action,
and instead of 5 minutes
I'll use 30 seconds for testing.
Now, one thing about this
Incremental Static Regeneration feature is that
it only applies when running in production mode.
So let me stop the server
and do another production build.
If we go and look at the full output now,
You can see that both "index-1a" and "1b"
have a filled circle next to them,
meaning they use "getStaticProps",
But "index-1b" also says "ISR: 30 Seconds",
where ISR is short for
Incremental Static Regeneration.
And by the way, note that if we use ISR
that means our website is no longer fully static,
so we can no longer do a "next export"
like we did with our Blog example.
We need to run it in Node.js
with "npm start",
or deploy it to a platform
that supports Next.js, like Vercel.
Anyway, now that we have the server running,
if we load our "index-1a" page
this now shows the "Aloe Vera - New!" title
because we rebuilt the app
so it fetched the latest data.
And if we load "1b"
of course it shows the same data initially.
But let's see what happens now
if we go and modify the content in the CMS.
I'll change the title to say
"Updated!" this time.
And now let's see what happens
if we reload "index-1b".
It still shows the old title
for the first product,
but if I keep reloading it,
after 30 seconds have passed,
at some point you'll see
that reloading the page
triggered a call to "getStaticProps".
We can see that in the server logs.
And the server fetched new data,
with the updated product title.
But strangely the title displayed on the page
is still the old one.
That's because,
when the "revalidate" period has passed
the first request to the server
causes Next.js to call "getStaticProps" again,
but it doesn't actually wait
for the new data to arrive.
Instead Next.js returns
the old page to the client,
so it can return it immediately,
while in the background it will
re-generate the page with the new data.
If we reload the page once more
this time we'll see the new product title
displayed in the page.
So it's interesting to note how
Next.js will return the old page
to the first request that triggers revalidation.
And it does that so that
the client does not have to wait.
The idea here is that
it's better to return the old page quickly
rather than make the user wait longer
to possibly see more recent data.
This is a sensible approach in many cases,
but keep this in mind when deciding
the best approach for your own use case.
Now, the other thing worth mentioning
is that Next.js doesn't know
if there is new data in our CMS.
It will simply call "getStaticProps" again
after the "revalidate" period,
whether there is new data or not.
And we can prove that by trying to
reload this page again.
After another 30 seconds we should see
that there are new messages in the server logs,
and it has re-fetched the data,
even though it hasn't changed in the CMS.
This shouldn't come as a surprise
given that Next.js has no way to know
if something has changed in our CMS.
That's how the page using ISR works.
Now, if we load page "1a",
that's the one without ISR
of course this still shows the old data,
and will keep showing the old data forever,
because this page will never be regenerated.
Unless we re-build the application of course.
So that's Incremental Static Regeneration.
It can be enabled with the "revalidate" option
in the object returned by "getStaticProps".
And it's a very good solution for cases where
your data may change, but not very often,
so it's ok to check for new data
every few minutes or so.
Your page will still be static HTML,
but will also be re-generated periodically,
meaning you can have most of the advantages
of the server side approach,
while also being able to reflect
any changes to the backend data automatically.