We implemented static generation
on the index JS and the eventId JS pages.
Now let's take a closer look.
It works, but maybe we can optimize it.
For example, on the starting page,
so this index JS page.
We are pre generating this page with the pre fetched data,
so to say,
but of course this data will then only update
if we build again.
So if our page was deployed for a couple of hours
or even days, and we have new featured events,
we need to redeploy our page
to reflect that latest state.
That's not ideal.
And one possible work around could be to use,
getStaticProps instead.
Then for every incoming request,
we would pre-render the page again on the fly
but this would be overkill here.
We don't need to pre generate this for every request,
just a couple of times, maybe after a certain time span.
And that's where we can add the revalidate key tutors object
which we returned side-by-side to the props key.
And we can set this to a value
of our choice to 10 seconds, 100 seconds, 10 minutes
whatever it makes sense to you.
Now, our events and the featured events
probably don't change that often.
And it's not the end of the world
if we did update them
and our starting page, doesn't immediately reflect this.
So maybe every 1,800 seconds is a good time span.
That means that every half hour we regenerate this page
for a new incoming request.
And I think that would work quite well here.
With that, this page still works,
but in production, it would be regenerated
from time to time,
at most once every half hour.
Now for eventId, we also could consider re-validating
because there it's similar.
If the details about any event changed,
we don't reflect this on our page
because we never regenerate it.
Again, we could use service side rendering for that
or we add clients site data fetching
so that we have some initial data
and we then update this with the client site data.
But we could also go for re-validating instead here,
and here I will also set revalidate to a certain interval.
Now, I will not go for half an hour here,
because for example,
if the date changes, that's more important
than the general list of featured events.
It's still okay if it's slightly outdated
but I wanna be more accurate
than on the starting page.
So, set this, let's say to 30 seconds,
so that if a new request comes in and it's more
than 30 seconds since the page was last generated,
it will be generated again.
I think that's a setting that makes sense here.
Of course, you can also go for a different duration
if that makes more sense to you though
or alternatively you solved as
with client site data fetching,
in addition to the pre rendering here.
Now, I also have an optimization idea
regarding getStaticPaths.
Currently, we're fetching all events here.
Now, in our case,
that's only free events,
but on a real page,
we could of course have hundreds or thousands of events.
So fetching all those events,
to pre generate all those pages
could be a huge waste that might really
be redundant and could lead to performance issues.
So in reality,
we might want to just pre-render our featured events
because those are more likely to be visited
because they're featured on the starting page.
So therefore here, in eventId on this eventId page,
instead of fetching all events and pre rendering
all the pages, all the detail pages for all events,
I will instead just load my featured events
and therefore import getFeaturedEvents
from the API util helper file,
and then just simply execute getFeaturedEvents down there.
But now with that, of course, that implies
that for some events, the page will not be pre-generated.
So if we leave fallback set to false, we'll have an issue.
If I click on some event, which was not, pre-generated
like this event with an idea of E1,
I get a 404 error
even though we have data for this event
but we didn't define it
in advance and therefore it wasn't pre-generated.
And since we tell next.js that we did prepare
all required pages here,
that's what we tell next.js with fallback false.
It shows as a 404 page here.
So the correct setting here,
would be true,
telling next.js that there are more pages
than the ones we prepared here.
Then it will try to dynamically generate the page
if it encounters a page which was not pre-generated before.
Now, if we do that, it works.
Now we see no event found initially
until the event was fetched
because we are checking if we don't have any event.
And then we showed us fallback and that's good.
We should show a fallback content
whilst we are waiting for the event to arrive
but here it might be better to show some
a loading spinner
or some loading text instead of an error.
Because here it's now actually expected for some events
which haven't been pre-generated
that we don't have them right from the start.
So instead of wrapping this into an error alert,
I'll wrap this in a regular div instead
and give that div a class name of center
which is a globally available class name
to find in the global CSS file.
And then I'll then say loading instead of no event found.
And therefore, now if we reload,
we see loading until the event is there
so that's better.
Alternatively, of course,
we set fallback, not too true, but to blocking.
In that case, next.js will not serve anything
until we're done generating this page.
So if I do that and reload,
then loading the page takes a bit longer
but we get the entire finished page
right from the start.
It's up to you which user experience you want on your page
or stick to this blocking approach
but you can go for either of the two.
And these were a couple of small optimized session steps
which I did want to implement.
Now with that, let's go back
to the two remaining pages we have,
maybe first to the index.js page and the events folder
and let's make sure we also pre-render those correctly
with data which is fetched in advance.
Try implementing it on your own.
We'll do it together in the next lecture.