So what's up with this fallback key here?
The fallback key can help you if you have
a lot of pages that would need to be pre-generated.
Here I only have three dummy products,
and I'm currently not even fetching
that data from that file.
We'll do that later,
but we only have three products.
Now imagine that you have like an Amazon-like website
with millions of products.
Of course, pre-generating all those products
like this might not be optimal,
not just because I hard coded this here.
We could fetch this dynamically from this file,
so that's not the problem,
but simply because pre-generating all
those millions of pages might take super long,
and there might be products,
let's say you're not Amazon, which are rarely visited.
If you're building a blog and you have hundreds of articles,
you might have some articles which are basically never read.
So then, pre-generating such rarely visited pages
is a waste of time and resources.
That's where fallback becomes important.
Here we can set this to true,
and then for example, we could decide
to only pre-render some pages.
So let's say we wanna pre-render the page
with product ID one.
So with P1, because that's a highly frequented page,
it's visited very often,
but we don't wanna pre-generate the other two pages.
With fallback set to true, that's possible
because now if I save this, you will notice
that if I go back to the starting page,
if I click on product three,
we still load this page successfully.
Even though it was not added here to paths.
And the reason for that is that with fallback true,
we tell NextJS that even pages which are not listed here.
So even parameter values for the PID parameter,
which are not listed here, can be valid.
Values that should be loaded when they are visited.
But they're not pre-generated,
instead they're generated just in time
when a request reaches the server.
And that allows us to pre-generate highly visited pages,
and postpone the generation to less frequented pages
to the server, so that they are only pre-generated
when they're needed.
So that can be a very useful behavior,
but you'll notice a problem here.
If I don't click on a link here,
but instead I directly enter this in URL,
and therefore send a new request to this page,
we actually get an error.
Cannot read property title of undefined.
The reason for that, is that this pre-generation,
this dynamic pre-generation, when it's needed,
does not finish instantly.
So therefore instead when using this fallback feature,
you should be prepared to return
a fallback state in your component.
For example, by simply checking if loaded product
is maybe not a thing with if not,
and then returning something like loading here.
And if you do this, and you add
this to your component function,
and you save everything,
if you now reload this page,
you'll see loading briefly
and then NextJS will automatically give you that data
once it's done loading.
So this is a little bit like the standard react solution
with user fact and set state, except for that
you don't need to do any of that.
You just get something through props,
you check if it's there yet,
and if it's not you show that fallback content,
and once it's there NextJS will automatically update
this component page for you,
and then return the regular content here.
So with that you see that now I can also reload this page
and we still load this successfully eventually,
because of that fallback feature.
An alternative would be
that you don't set fallback to true or false,
but to a string with a value of blocking.
If you do that, then you don't even need
that fallback check here in the component,
and hence we can comment this out,
because then NextJS will actually wait
for this page to fully be pre-generated on the server
before it serves that.
So then it will take a little bit longer
for the visitor of the page to get a response,
but the response which is sent back will be finished.
So for now reload that still works.
It just takes a bit longer.
And again it's up to you which approach you need
for your application.
Sometimes it's important to show something quickly,
especially if you know that generating the page
and fetching the data might take a bit longer.
Sometimes it's worth to wait for it.
And you don't want to show
an incomplete page to your visitors
in such a case, blocking can be better.
Here you saw both and as you see both is super easy to use.