All language subtitles for 009 Utilizing Incremental Static Generation (ISR)_Downloadly.ir_en

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.