So we did learn about get static props,
and how we can use it to prepare data on the server side
so to say, for pre-rendering the page.
However, when I say on the server side,
that's only partially correct.
We can execute server-side code here, but in the end
the code will not run on the actual server, which serves
our application, instead it runs on our machine
when the page is built when the application
is built with next.
So in the end, when you run, NPM run build.
When you execute that prepared script here,
which executes next build, then this code is executed.
Now that's still good because since we have no JS installed
all that node JS code does work here.
So that's perfect, but it has one potential downside.
What if you have data that changes frequently?
Because I mean, pre-generating the pages sounds great
if you're building something fairly static.
If you're building a blog, where data
doesn't change too often, then of course,
whenever you add a new blog post,
you can just pre-generate your project again,
you can run NPM run build again,
and deploy the updated project.
So that would work.
But if you have data that changes more frequently,
if we add a fourth product here
after the page was deployed, then we have to rebuild
and redeploy the page all the time.
And that doesn't sound like a great thing to do.
Well, Next.js also has solutions for this.
Solution number one is that you do pre-build your page,
but then you still include standard react code
in your react components, where you use, use effect
for then fetching updated data from a server.
So you would always serve back a page
with some pre-rendered data,
but that data might be outdated.
So you fetched a latest data in the background
and then update the loaded page after that data arrived.
That's a pattern you could implement.
Then you at least chose something to your users,
but it might be a bit outdated,
but that's why you're fetching data in the background,
so that you can update the page
with the latest data once you got that.
That might be a perfectly valid pattern,
but there is an alternative which often is better.
This get static props function, as I mentioned does execute
when you build your project with next build,
so with this build script.
Well, that's not entirely true.
It does execute there, but that is not necessarily
the only time it executes.
Instead, Next.js has a built in feature,
which is called incremental static generation.
It means that you don't just generate
your page statically once at build time,
but that it's continuously updated
even after deployment without you re-deploying it.
So you pre-generate a page, but then you can also
tell Next.js that a given page should be re-generated again
for every incoming request at most every X seconds.
So every 60 seconds, for example.
That means that if a request is made
for a certain page and it's, let's say less than 60 seconds
since it was last re-generated, the existing page
would be served to the visitor.
But if it's past those 60 seconds
and the amount of seconds of course is up to you,
then this page would be pre-generated on the server instead.
So that means that you either serve the old page
if it's not that old yet, or you serve the latest page
and brand new page, which was generated again
on the server otherwise.
And if that page was pre-generated again
on the server, because it was outdated,
then this newly generated page
will replace the existing old page on the server.
It will be cashed and future visitors
will see that re-generated page instead.
Until 60 seconds passed again,
and then new page is pre-generated again.
So you can have ongoing pre-rendering on the server
for incoming requests.
And all you need to do to unlock this is in the object,
which you return in get static props.
You don't just return props,
but you also add a second key, which is called revalidate.
And as a value, you set a number a year,
which is the time in seconds that Next.js
should wait until it re-generates this page.
So for example, if I enter 10 here, we would tell Next.js
that for every incoming request to this page,
it should be re-generated unless,
it's less than 10 seconds ago that it was last re-generated.
So it's recreated at most once every 10 seconds.
And of course the higher this number is,
the less this page will be re-generated.
And it's totally up to you which value you want here.
It will of course depend on which kind of application
you're building.
For a highly dynamic page where content changes
all the time, you want a very low value,
maybe just one second.
For pages where the content is less dynamic,
maybe 10 minutes is enough.
So that is then really something you have to decide.
Now during development, the page will be re-generated
for every request, no matter what you enter here.
So with the development server, we will always see
the latest page with the latest data,
and this will always run again.
But in production this number will matter.
So here, if I add, re-generating here in a console log,
instead of get static props, if I now rerun
the development server, we will see here in this terminal,
since that is server side terminal, so to say,
we see re-generating, because I started the Def server.
So that's equivalent to the build process.
It was now pre-generated.
But if I now visit this page by reloading, for example
we see this again, because as I just said,
during development, the revalidate number doesn't matter.
It will re-generate it every time.
In production it will matter,
and then you have the best of both worlds.
You have a pre-rendered page,
which then still is updated after deployment,
just as defined by you.