1
00:00:02,000 --> 00:00:04,000
We implemented static generation

2
00:00:04,000 --> 00:00:08,000
on the index JS and the eventId JS pages.

3
00:00:08,000 --> 00:00:10,000
Now let's take a closer look.

4
00:00:10,000 --> 00:00:13,000
It works, but maybe we can optimize it.

5
00:00:13,000 --> 00:00:15,000
For example, on the starting page,

6
00:00:15,000 --> 00:00:17,000
so this index JS page.

7
00:00:17,000 --> 00:00:22,000
We are pre generating this page with the pre fetched data,

8
00:00:23,000 --> 00:00:23,000
so to say,

9
00:00:23,000 --> 00:00:27,000
but of course this data will then only update

10
00:00:27,000 --> 00:00:29,000
if we build again.

11
00:00:29,000 --> 00:00:32,000
So if our page was deployed for a couple of hours

12
00:00:32,000 --> 00:00:37,000
or even days, and we have new featured events,

13
00:00:37,000 --> 00:00:39,000
we need to redeploy our page

14
00:00:39,000 --> 00:00:42,000
to reflect that latest state.

15
00:00:42,000 --> 00:00:43,000
That's not ideal.

16
00:00:43,000 --> 00:00:46,000
And one possible work around could be to use,

17
00:00:46,000 --> 00:00:49,000
getStaticProps instead.

18
00:00:49,000 --> 00:00:52,000
Then for every incoming request,

19
00:00:52,000 --> 00:00:55,000
we would pre-render the page again on the fly

20
00:00:55,000 --> 00:00:58,000
but this would be overkill here.

21
00:00:58,000 --> 00:01:02,000
We don't need to pre generate this for every request,

22
00:01:02,000 --> 00:01:07,000
just a couple of times, maybe after a certain time span.

23
00:01:07,000 --> 00:01:11,000
And that's where we can add the revalidate key tutors object

24
00:01:11,000 --> 00:01:15,000
which we returned side-by-side to the props key.

25
00:01:15,000 --> 00:01:17,000
And we can set this to a value

26
00:01:17,000 --> 00:01:22,000
of our choice to 10 seconds, 100 seconds, 10 minutes

27
00:01:23,000 --> 00:01:25,000
whatever it makes sense to you.

28
00:01:25,000 --> 00:01:27,000
Now, our events and the featured events

29
00:01:27,000 --> 00:01:30,000
probably don't change that often.

30
00:01:30,000 --> 00:01:31,000
And it's not the end of the world

31
00:01:31,000 --> 00:01:33,000
if we did update them

32
00:01:33,000 --> 00:01:37,000
and our starting page, doesn't immediately reflect this.

33
00:01:37,000 --> 00:01:42,000
So maybe every 1,800 seconds is a good time span.

34
00:01:43,000 --> 00:01:48,000
That means that every half hour we regenerate this page

35
00:01:48,000 --> 00:01:51,000
for a new incoming request.

36
00:01:51,000 --> 00:01:54,000
And I think that would work quite well here.

37
00:01:54,000 --> 00:01:56,000
With that, this page still works,

38
00:01:56,000 --> 00:01:59,000
but in production, it would be regenerated

39
00:01:59,000 --> 00:02:00,000
from time to time,

40
00:02:00,000 --> 00:02:03,000
at most once every half hour.

41
00:02:05,000 --> 00:02:09,000
Now for eventId, we also could consider re-validating

42
00:02:09,000 --> 00:02:12,000
because there it's similar.

43
00:02:12,000 --> 00:02:15,000
If the details about any event changed,

44
00:02:15,000 --> 00:02:17,000
we don't reflect this on our page

45
00:02:17,000 --> 00:02:20,000
because we never regenerate it.

46
00:02:20,000 --> 00:02:24,000
Again, we could use service side rendering for that

47
00:02:24,000 --> 00:02:26,000
or we add clients site data fetching

48
00:02:26,000 --> 00:02:28,000
so that we have some initial data

49
00:02:28,000 --> 00:02:32,000
and we then update this with the client site data.

50
00:02:32,000 --> 00:02:37,000
But we could also go for re-validating instead here,

51
00:02:37,000 --> 00:02:42,000
and here I will also set revalidate to a certain interval.

52
00:02:42,000 --> 00:02:45,000
Now, I will not go for half an hour here,

53
00:02:45,000 --> 00:02:46,000
because for example,

54
00:02:46,000 --> 00:02:48,000
if the date changes, that's more important

55
00:02:48,000 --> 00:02:53,000
than the general list of featured events.

56
00:02:53,000 --> 00:02:56,000
It's still okay if it's slightly outdated

57
00:02:56,000 --> 00:02:58,000
but I wanna be more accurate

58
00:02:58,000 --> 00:03:00,000
than on the starting page.

59
00:03:00,000 --> 00:03:03,000
So, set this, let's say to 30 seconds,

60
00:03:03,000 --> 00:03:06,000
so that if a new request comes in and it's more

61
00:03:06,000 --> 00:03:10,000
than 30 seconds since the page was last generated,

62
00:03:10,000 --> 00:03:12,000
it will be generated again.

63
00:03:12,000 --> 00:03:15,000
I think that's a setting that makes sense here.

64
00:03:15,000 --> 00:03:17,000
Of course, you can also go for a different duration

65
00:03:17,000 --> 00:03:20,000
if that makes more sense to you though

66
00:03:20,000 --> 00:03:22,000
or alternatively you solved as

67
00:03:22,000 --> 00:03:24,000
with client site data fetching,

68
00:03:24,000 --> 00:03:28,000
in addition to the pre rendering here.

69
00:03:28,000 --> 00:03:30,000
Now, I also have an optimization idea

70
00:03:30,000 --> 00:03:33,000
regarding getStaticPaths.

71
00:03:33,000 --> 00:03:36,000
Currently, we're fetching all events here.

72
00:03:36,000 --> 00:03:37,000
Now, in our case,

73
00:03:37,000 --> 00:03:39,000
that's only free events,

74
00:03:39,000 --> 00:03:41,000
but on a real page,

75
00:03:41,000 --> 00:03:44,000
we could of course have hundreds or thousands of events.

76
00:03:45,000 --> 00:03:48,000
So fetching all those events,

77
00:03:48,000 --> 00:03:51,000
to pre generate all those pages

78
00:03:51,000 --> 00:03:54,000
could be a huge waste that might really

79
00:03:54,000 --> 00:03:57,000
be redundant and could lead to performance issues.

80
00:03:58,000 --> 00:04:00,000
So in reality,

81
00:04:00,000 --> 00:04:04,000
we might want to just pre-render our featured events

82
00:04:04,000 --> 00:04:07,000
because those are more likely to be visited

83
00:04:07,000 --> 00:04:09,000
because they're featured on the starting page.

84
00:04:10,000 --> 00:04:14,000
So therefore here, in eventId on this eventId page,

85
00:04:14,000 --> 00:04:18,000
instead of fetching all events and pre rendering

86
00:04:18,000 --> 00:04:22,000
all the pages, all the detail pages for all events,

87
00:04:22,000 --> 00:04:25,000
I will instead just load my featured events

88
00:04:25,000 --> 00:04:28,000
and therefore import getFeaturedEvents

89
00:04:28,000 --> 00:04:30,000
from the API util helper file,

90
00:04:32,000 --> 00:04:37,000
and then just simply execute getFeaturedEvents down there.

91
00:04:39,000 --> 00:04:42,000
But now with that, of course, that implies

92
00:04:42,000 --> 00:04:47,000
that for some events, the page will not be pre-generated.

93
00:04:47,000 --> 00:04:52,000
So if we leave fallback set to false, we'll have an issue.

94
00:04:52,000 --> 00:04:56,000
If I click on some event, which was not, pre-generated

95
00:04:56,000 --> 00:04:59,000
like this event with an idea of E1,

96
00:04:59,000 --> 00:05:02,000
I get a 404 error

97
00:05:02,000 --> 00:05:05,000
even though we have data for this event

98
00:05:05,000 --> 00:05:07,000
but we didn't define it

99
00:05:07,000 --> 00:05:10,000
in advance and therefore it wasn't pre-generated.

100
00:05:10,000 --> 00:05:14,000
And since we tell next.js that we did prepare

101
00:05:14,000 --> 00:05:15,000
all required pages here,

102
00:05:15,000 --> 00:05:20,000
that's what we tell next.js with fallback false.

103
00:05:20,000 --> 00:05:23,000
It shows as a 404 page here.

104
00:05:23,000 --> 00:05:25,000
So the correct setting here,

105
00:05:25,000 --> 00:05:27,000
would be true,

106
00:05:27,000 --> 00:05:30,000
telling next.js that there are more pages

107
00:05:30,000 --> 00:05:32,000
than the ones we prepared here.

108
00:05:33,000 --> 00:05:36,000
Then it will try to dynamically generate the page

109
00:05:36,000 --> 00:05:41,000
if it encounters a page which was not pre-generated before.

110
00:05:41,000 --> 00:05:44,000
Now, if we do that, it works.

111
00:05:44,000 --> 00:05:46,000
Now we see no event found initially

112
00:05:46,000 --> 00:05:48,000
until the event was fetched

113
00:05:48,000 --> 00:05:52,000
because we are checking if we don't have any event.

114
00:05:52,000 --> 00:05:56,000
And then we showed us fallback and that's good.

115
00:05:56,000 --> 00:05:59,000
We should show a fallback content

116
00:05:59,000 --> 00:06:03,000
whilst we are waiting for the event to arrive

117
00:06:03,000 --> 00:06:06,000
but here it might be better to show some

118
00:06:06,000 --> 00:06:07,000
a loading spinner

119
00:06:07,000 --> 00:06:10,000
or some loading text instead of an error.

120
00:06:10,000 --> 00:06:13,000
Because here it's now actually expected for some events

121
00:06:13,000 --> 00:06:15,000
which haven't been pre-generated

122
00:06:15,000 --> 00:06:18,000
that we don't have them right from the start.

123
00:06:18,000 --> 00:06:21,000
So instead of wrapping this into an error alert,

124
00:06:21,000 --> 00:06:24,000
I'll wrap this in a regular div instead

125
00:06:24,000 --> 00:06:29,000
and give that div a class name of center

126
00:06:29,000 --> 00:06:32,000
which is a globally available class name

127
00:06:32,000 --> 00:06:34,000
to find in the global CSS file.

128
00:06:36,000 --> 00:06:41,000
And then I'll then say loading instead of no event found.

129
00:06:41,000 --> 00:06:43,000
And therefore, now if we reload,

130
00:06:43,000 --> 00:06:47,000
we see loading until the event is there

131
00:06:47,000 --> 00:06:48,000
so that's better.

132
00:06:48,000 --> 00:06:50,000
Alternatively, of course,

133
00:06:50,000 --> 00:06:55,000
we set fallback, not too true, but to blocking.

134
00:06:55,000 --> 00:06:58,000
In that case, next.js will not serve anything

135
00:06:58,000 --> 00:07:01,000
until we're done generating this page.

136
00:07:01,000 --> 00:07:03,000
So if I do that and reload,

137
00:07:03,000 --> 00:07:06,000
then loading the page takes a bit longer

138
00:07:06,000 --> 00:07:09,000
but we get the entire finished page

139
00:07:09,000 --> 00:07:11,000
right from the start.

140
00:07:11,000 --> 00:07:15,000
It's up to you which user experience you want on your page

141
00:07:15,000 --> 00:07:17,000
or stick to this blocking approach

142
00:07:17,000 --> 00:07:21,000
but you can go for either of the two.

143
00:07:21,000 --> 00:07:24,000
And these were a couple of small optimized session steps

144
00:07:24,000 --> 00:07:27,000
which I did want to implement.

145
00:07:27,000 --> 00:07:28,000
Now with that, let's go back

146
00:07:28,000 --> 00:07:30,000
to the two remaining pages we have,

147
00:07:30,000 --> 00:07:34,000
maybe first to the index.js page and the events folder

148
00:07:34,000 --> 00:07:38,000
and let's make sure we also pre-render those correctly

149
00:07:38,000 --> 00:07:41,000
with data which is fetched in advance.

150
00:07:41,000 --> 00:07:43,000
Try implementing it on your own.

151
00:07:43,000 --> 00:07:45,000
We'll do it together in the next lecture.