1
00:00:03,000 --> 00:00:06,226
In this section we've seen different ways

2
00:00:06,226 --> 00:00:08,822
to render our pages with Next.js.

3
00:00:08,901 --> 00:00:11,037
Let's do a quick recap now,

4
00:00:11,037 --> 00:00:13,717
so you can better understand when to use

5
00:00:13,717 --> 00:00:16,128
which approach in your own projects.

6
00:00:16,195 --> 00:00:18,875
We started the course by using static

7
00:00:18,875 --> 00:00:20,686
rendering for everything.

8
00:00:20,758 --> 00:00:24,280
All our pages were generated at build time,

9
00:00:24,280 --> 00:00:26,839
which meant we could also export

10
00:00:26,839 --> 00:00:29,079
our app as a static website.

11
00:00:29,159 --> 00:00:31,621
This approach has the advantage that,

12
00:00:31,621 --> 00:00:32,819
for every request,

13
00:00:32,886 --> 00:00:35,347
the server just needs to return

14
00:00:35,347 --> 00:00:37,094
an existing HTML file.

15
00:00:37,173 --> 00:00:39,217
That means our users can get

16
00:00:39,217 --> 00:00:40,968
a response very quickly,

17
00:00:41,041 --> 00:00:43,728
and the server doesn't use much

18
00:00:43,728 --> 00:00:45,721
CPU or other resources.

19
00:00:45,808 --> 00:00:47,938
At the other end of the spectrum

20
00:00:47,938 --> 00:00:49,669
we have dynamic rendering,

21
00:00:49,735 --> 00:00:53,426
where each page is generated at run time,

22
00:00:53,426 --> 00:00:56,169
every time a client requests it.

23
00:00:56,169 --> 00:00:59,269
This allows us to display the latest data,

24
00:00:59,269 --> 00:01:03,221
but it comes at the cost of slower response times,

25
00:01:03,221 --> 00:01:05,952
and higher server utilization.

26
00:01:05,952 --> 00:01:09,535
Next.js then provides some features that sit

27
00:01:09,535 --> 00:01:11,624
somewhere in the middle between

28
00:01:11,624 --> 00:01:12,904
these two extremes.

29
00:01:12,972 --> 00:01:16,730
If we have a dynamic route, like our ReviewPage,

30
00:01:16,730 --> 00:01:20,176
we can write a generateStaticParams function

31
00:01:20,176 --> 00:01:22,655
and render all possible pages

32
00:01:22,655 --> 00:01:24,792
statically at build time.

33
00:01:24,878 --> 00:01:28,598
However if we request a new path at runtime

34
00:01:28,598 --> 00:01:31,246
by default Next.js will generate

35
00:01:31,246 --> 00:01:33,150
the new page on demand.

36
00:01:33,233 --> 00:01:35,895
This way all our pages are static,

37
00:01:35,895 --> 00:01:38,575
but we can still add new pages without

38
00:01:38,575 --> 00:01:40,550
redeploying our application.

39
00:01:40,620 --> 00:01:43,796
Then we've seen Time-based Revalidation,

40
00:01:43,796 --> 00:01:46,552
which lets us generate static pages

41
00:01:46,552 --> 00:01:48,751
but also make them expire after

42
00:01:48,751 --> 00:01:50,737
a certain number of seconds,

43
00:01:50,808 --> 00:01:53,868
causing them to be regenerated periodically.

44
00:01:53,868 --> 00:01:57,439
So if the data changes the pages will update,

45
00:01:57,439 --> 00:02:00,085
albeit not immediately, but after

46
00:02:00,085 --> 00:02:02,169
the time interval expires.

47
00:02:02,249 --> 00:02:04,979
On-demand Revalidation is even better

48
00:02:04,979 --> 00:02:07,783
in that it lets you rerender your pages

49
00:02:07,783 --> 00:02:09,794
as soon as the data changes,

50
00:02:09,866 --> 00:02:12,209
and only when the data changes.

51
00:02:12,209 --> 00:02:14,616
If you use a CMS that supports

52
00:02:14,616 --> 00:02:16,381
webhook notifications,

53
00:02:16,462 --> 00:02:19,254
or have some other way to know exactly

54
00:02:19,254 --> 00:02:21,165
when the data is modified,

55
00:02:21,238 --> 00:02:23,464
this can be a great solution.

56
00:02:23,464 --> 00:02:25,767
Now, I shall also point out that

57
00:02:25,767 --> 00:02:29,044
all these approaches are server based.

58
00:02:29,044 --> 00:02:31,076
Whether our pages are rendered

59
00:02:31,076 --> 00:02:32,837
statically or dynamically,

60
00:02:32,904 --> 00:02:36,124
the data is always loaded on the server,

61
00:02:36,124 --> 00:02:38,589
in a React Server Component,

62
00:02:38,589 --> 00:02:41,380
and the server returns prerendered

63
00:02:41,380 --> 00:02:43,022
HTML to the browser.

64
00:02:43,104 --> 00:02:45,226
It's also possible to load

65
00:02:45,226 --> 00:02:47,184
data on the client side,

66
00:02:47,266 --> 00:02:49,427
calling "fetch" in the browser.

67
00:02:49,427 --> 00:02:51,667
This is how traditional Single

68
00:02:51,667 --> 00:02:53,385
Page Applications work,

69
00:02:53,460 --> 00:02:56,647
and you can still do that even with Next.js,

70
00:02:56,647 --> 00:02:58,984
by using Client Components.

71
00:02:58,984 --> 00:03:02,333
Although if you fetch data on the client side,

72
00:03:02,333 --> 00:03:05,851
you lose all the advantages of prerendering.

73
00:03:05,851 --> 00:03:08,600
So, given all these different options,

74
00:03:08,600 --> 00:03:10,324
which one should you choose?

75
00:03:10,324 --> 00:03:13,334
As always, it depends on your requirements.

76
00:03:13,334 --> 00:03:15,249
If you have a page showing

77
00:03:15,249 --> 00:03:17,017
data that never changes,

78
00:03:17,091 --> 00:03:19,331
obviously it should be static.

79
00:03:19,331 --> 00:03:21,692
If the data can change, but it's

80
00:03:21,692 --> 00:03:23,389
the same for all users,

81
00:03:23,463 --> 00:03:25,415
then you can opt for one of

82
00:03:25,415 --> 00:03:27,224
the "static+" approaches.

83
00:03:27,296 --> 00:03:30,668
If you only want to be able to add new pages,

84
00:03:30,668 --> 00:03:32,896
then the default dynamicParams

85
00:03:32,896 --> 00:03:34,604
behavior may be enough.

86
00:03:34,678 --> 00:03:38,410
While if you also need to modify existing content

87
00:03:38,410 --> 00:03:40,635
then you can use Revalidation.

88
00:03:40,635 --> 00:03:43,143
Either On-demand Revalidation,

89
00:03:43,143 --> 00:03:45,475
if you have a way to get notified

90
00:03:45,475 --> 00:03:47,030
when the data changes,

91
00:03:47,100 --> 00:03:49,413
or otherwise use Revalidation

92
00:03:49,413 --> 00:03:51,087
with a time interval.

93
00:03:51,167 --> 00:03:55,482
If your page must display the very latest data,

94
00:03:55,482 --> 00:03:57,819
or user-specific data, that's

95
00:03:57,819 --> 00:04:00,076
different for every request,

96
00:04:00,157 --> 00:04:02,653
then you need dynamic rendering.

97
00:04:02,653 --> 00:04:05,272
In this case you could also consider

98
00:04:05,272 --> 00:04:07,164
client-side data fetching.

99
00:04:07,237 --> 00:04:10,349
We'll see an example of that in a later section.

100
00:04:10,349 --> 00:04:13,369
Now, from our previous videos we know that

101
00:04:13,369 --> 00:04:15,818
when using "fetch" to load data,

102
00:04:15,818 --> 00:04:17,949
the fetch options can affect

103
00:04:17,949 --> 00:04:19,851
how the page is rendered.

104
00:04:19,928 --> 00:04:23,161
Fetch and rendering usually go hand in hand,

105
00:04:23,161 --> 00:04:25,971
however they are two separate things,

106
00:04:25,971 --> 00:04:27,882
and there are cases where they

107
00:04:27,882 --> 00:04:29,346
can behave differently.

108
00:04:29,410 --> 00:04:31,678
Let me go through a few examples.

109
00:04:31,678 --> 00:04:34,812
If we set "force-dynamic" in our page

110
00:04:34,812 --> 00:04:37,650
that also disables the fetch cache.

111
00:04:37,650 --> 00:04:41,202
This is documented in the Next.js reference

112
00:04:41,202 --> 00:04:43,267
for the "dynamic" option.

113
00:04:43,350 --> 00:04:46,360
If we configure our page to "revalidate",

114
00:04:46,360 --> 00:04:48,759
that will effectively apply the same

115
00:04:48,759 --> 00:04:50,891
setting to any "fetch" requests.

116
00:04:50,957 --> 00:04:54,181
So, usually the options we set in our page

117
00:04:54,181 --> 00:04:56,512
will propagate to the "fetch"

118
00:04:56,512 --> 00:04:58,683
requests made by that page.

119
00:04:58,763 --> 00:05:01,142
But, we can also choose to configure

120
00:05:01,142 --> 00:05:02,859
the "fetch" calls instead.

121
00:05:02,925 --> 00:05:05,949
If we set "cache" to "no-store"

122
00:05:05,949 --> 00:05:07,980
that will cause our page to

123
00:05:07,980 --> 00:05:09,784
be rendered dynamically.

124
00:05:09,859 --> 00:05:12,274
We've seen this in one of our tests.

125
00:05:12,274 --> 00:05:15,641
And if we set "revalidate" for a fetch request,

126
00:05:15,641 --> 00:05:19,053
that will also cause the page to be regenerated

127
00:05:19,053 --> 00:05:21,376
based on the same time interval.

128
00:05:21,449 --> 00:05:24,391
Now, let's take a look at some other scenarios.

129
00:05:24,391 --> 00:05:26,575
The same page could make more

130
00:05:26,575 --> 00:05:28,307
than one fetch request,

131
00:05:28,382 --> 00:05:30,888
if it includes multiple components

132
00:05:30,888 --> 00:05:32,952
that display different data.

133
00:05:33,026 --> 00:05:36,555
And each fetch request could set its own options,

134
00:05:36,555 --> 00:05:39,262
like different "revalidate" intervals.

135
00:05:39,262 --> 00:05:42,785
In that case when rendering the pageÂ Next.js

136
00:05:42,785 --> 00:05:45,187
will use the shorter interval,

137
00:05:45,267 --> 00:05:48,444
because if some data can change more often

138
00:05:48,444 --> 00:05:51,393
then the page also needs to be re-rendered

139
00:05:51,393 --> 00:05:52,938
at the same frequency.

140
00:05:53,008 --> 00:05:57,432
Similarly, if one fetch request uses revalidation,

141
00:05:57,432 --> 00:06:00,771
but another one sets "cache" to "no-store",

142
00:06:00,771 --> 00:06:04,127
then disabling the cache will take precedence,

143
00:06:04,127 --> 00:06:07,314
meaning the page will be treated as dynamic.

144
00:06:07,314 --> 00:06:09,178
Another interesting case is

145
00:06:09,178 --> 00:06:12,109
what happens if we have conflicting values

146
00:06:12,109 --> 00:06:13,948
in the page configuration versus

147
00:06:13,948 --> 00:06:15,327
the fetch configuration?

148
00:06:15,385 --> 00:06:17,675
For example, if the page sets a

149
00:06:17,675 --> 00:06:19,817
longer "revalidate" interval.

150
00:06:19,891 --> 00:06:22,651
Again, the shorter interval wins,

151
00:06:22,651 --> 00:06:26,190
meaning that the page configuration will effectively

152
00:06:26,190 --> 00:06:28,504
be overwritten by the fetch value.

153
00:06:28,573 --> 00:06:30,105
In all these examples,

154
00:06:30,105 --> 00:06:33,684
in the end Next.js will use similar settings

155
00:06:33,684 --> 00:06:36,876
for both fetch and page rendering.

156
00:06:36,876 --> 00:06:39,013
But that's not always the case.

157
00:06:39,013 --> 00:06:41,230
If we don't set any options,

158
00:06:41,230 --> 00:06:45,342
then fetch will cache all responses by default.

159
00:06:45,342 --> 00:06:48,874
While the page will use "dynamic: auto",

160
00:06:48,874 --> 00:06:52,044
which will try to cache as much as possible.

161
00:06:52,044 --> 00:06:55,711
Frequently this results in the page to be static.

162
00:06:55,711 --> 00:06:57,391
And, again, that's in line

163
00:06:57,391 --> 00:06:58,941
with the fetch behavior.

164
00:06:59,006 --> 00:07:01,310
But in some cases the page will

165
00:07:01,310 --> 00:07:03,540
be treated as dynamic instead.

166
00:07:03,614 --> 00:07:05,822
This happens if, for example,

167
00:07:05,822 --> 00:07:08,425
you have a dynamic route without

168
00:07:08,425 --> 00:07:10,296
"generateStaticParams".

169
00:07:10,377 --> 00:07:13,234
In this case the page will be rendered

170
00:07:13,234 --> 00:07:15,414
dynamically at every request,

171
00:07:15,489 --> 00:07:18,526
but fetch will use cached data.

172
00:07:18,526 --> 00:07:21,807
We'll see an example of this in the next section.

173
00:07:21,807 --> 00:07:24,061
Now, some of you may be thinking:

174
00:07:24,061 --> 00:07:27,401
what if I'm not using "fetch" in my application?

175
00:07:27,401 --> 00:07:29,589
What if I'm loading data directly

176
00:07:29,589 --> 00:07:31,180
from a database instead?

177
00:07:31,247 --> 00:07:33,605
In that scenario you can always

178
00:07:33,605 --> 00:07:35,735
use the page-level settings,

179
00:07:35,811 --> 00:07:38,782
because after all your database will only

180
00:07:38,782 --> 00:07:41,390
be called when the page is rendered.

181
00:07:41,463 --> 00:07:43,622
But if you do need to manually

182
00:07:43,622 --> 00:07:45,277
cache database results,

183
00:07:45,349 --> 00:07:48,820
React provides a "cache" function to do that.

184
00:07:48,820 --> 00:07:50,745
You can find out more in the

185
00:07:50,745 --> 00:07:52,258
Next.js documentation.

