1
00:00:03,000 --> 00:00:06,276
We configured the Home and Reviews pages

2
00:00:06,276 --> 00:00:08,979
to "revalidate" every 30 seconds,

3
00:00:09,061 --> 00:00:12,175
so if we publish a new entry in the CMS

4
00:00:12,175 --> 00:00:14,653
the pages will display the new data,

5
00:00:14,653 --> 00:00:17,136
albeit after a short interval.

6
00:00:17,136 --> 00:00:19,434
Now, there's another way to enable

7
00:00:19,434 --> 00:00:21,056
Background Revalidation:

8
00:00:21,123 --> 00:00:24,253
instead of configuring it at the page level,

9
00:00:24,253 --> 00:00:26,471
we can specify a similar option

10
00:00:26,471 --> 00:00:28,618
when making a "fetch" request,

11
00:00:28,689 --> 00:00:30,947
because, after all, it's the data

12
00:00:30,947 --> 00:00:32,658
we fetch that can change,

13
00:00:32,726 --> 00:00:35,837
making it necessary to re-render the page.

14
00:00:35,837 --> 00:00:38,134
So, let's try this other approach,

15
00:00:38,134 --> 00:00:40,939
by removing "revalidate" from the page.

16
00:00:40,939 --> 00:00:44,096
And we'll need to do the same in the ReviewsPage.

17
00:00:44,096 --> 00:00:46,677
As for the individual ReviewPage,

18
00:00:46,677 --> 00:00:49,057
we didn't set "revalidate" here,

19
00:00:49,057 --> 00:00:51,857
but this also fetches data from the CMS,

20
00:00:51,857 --> 00:00:53,425
by calling "getReview",

21
00:00:53,425 --> 00:00:56,345
that in turn uses "fetchReviews".

22
00:00:56,345 --> 00:00:58,456
In the end all CMS requests

23
00:00:58,456 --> 00:01:00,488
are made by this function.

24
00:01:00,566 --> 00:01:02,821
So to keep things simple we'll

25
00:01:02,821 --> 00:01:04,926
configure revalidation here.

26
00:01:05,001 --> 00:01:07,943
"fetch" accepts an optional second argument

27
00:01:07,943 --> 00:01:11,189
that's an object when we can set request options.

28
00:01:11,189 --> 00:01:13,767
Most of these settings are standard,

29
00:01:13,767 --> 00:01:15,809
like "cache" for example.

30
00:01:15,809 --> 00:01:18,361
If we set this to "no-store",

31
00:01:18,361 --> 00:01:20,977
this will tell Next.js not to save

32
00:01:20,977 --> 00:01:23,055
any responses to the cache.

33
00:01:23,132 --> 00:01:24,961
Let me show you this in action,

34
00:01:24,961 --> 00:01:26,723
since disabling the fetch

35
00:01:26,723 --> 00:01:28,485
cache can also be useful.

36
00:01:28,556 --> 00:01:30,097
Let's do a new build,

37
00:01:30,379 --> 00:01:33,770
and I didn't delete the ".next" folder because

38
00:01:33,770 --> 00:01:36,350
we disabled the fetch cache anyway.

39
00:01:36,423 --> 00:01:39,867
You can see that by setting "cache" to "no-store"

40
00:01:39,867 --> 00:01:42,699
Next.js treats our Home and

41
00:01:42,699 --> 00:01:45,322
Reviews pages as dynamic.

42
00:01:45,427 --> 00:01:47,713
If you remember, the "dynamic"

43
00:01:47,713 --> 00:01:49,846
behavior defaults to "auto",

44
00:01:49,922 --> 00:01:53,690
which means that Next.js decides automatically

45
00:01:53,690 --> 00:01:56,525
based on what our page code does.

46
00:01:56,525 --> 00:01:59,434
Since these pages call "fetch" with

47
00:01:59,434 --> 00:02:01,595
"cache" set to "no-store",

48
00:02:01,678 --> 00:02:04,353
Next.js figured out that these pages

49
00:02:04,353 --> 00:02:06,731
need to be rendered dynamically,

50
00:02:06,806 --> 00:02:09,683
in order to display the latest data.

51
00:02:09,683 --> 00:02:12,179
So, setting "cache" to "no-store"

52
00:02:12,179 --> 00:02:13,692
has a similar effect

53
00:02:13,768 --> 00:02:17,482
to configuring our pages with "force-dynamic".

54
00:02:17,482 --> 00:02:20,234
Now, the "reviews/[slug]" route still

55
00:02:20,234 --> 00:02:22,465
shows as statically generated,

56
00:02:22,540 --> 00:02:24,238
which is a bit misleading.

57
00:02:24,238 --> 00:02:26,067
The build did generate all

58
00:02:26,067 --> 00:02:27,896
the existing review pages,

59
00:02:27,967 --> 00:02:31,419
because we have a "generateStaticParams" function,

60
00:02:31,419 --> 00:02:34,384
but since we disabled the "fetch" cache

61
00:02:34,384 --> 00:02:37,733
it should refetch the data at every request.

62
00:02:37,733 --> 00:02:40,904
This build output is a bit of a simplification.

63
00:02:40,904 --> 00:02:42,825
It doesn't always take all

64
00:02:42,825 --> 00:02:44,672
the details into account.

65
00:02:44,746 --> 00:02:47,317
Anyway, let's go and start the server

66
00:02:47,317 --> 00:02:50,340
and see how our application works in practice.

67
00:02:50,340 --> 00:02:52,432
You can see that it rendered

68
00:02:52,432 --> 00:02:54,225
the HomePage at runtime,

69
00:02:54,300 --> 00:02:57,064
along with all the linked pages.

70
00:02:57,064 --> 00:02:59,555
And if I clear the logs, and reload,

71
00:02:59,555 --> 00:03:02,320
the server renders all the pages again.

72
00:03:02,320 --> 00:03:06,097
Every time we request the page, it's regenerated.

73
00:03:06,097 --> 00:03:08,967
It will be the same for the Reviews page,

74
00:03:08,967 --> 00:03:11,682
and each individual review as well.

75
00:03:11,682 --> 00:03:14,883
So all the pages are effectively "dynamic",

76
00:03:14,883 --> 00:03:16,853
just like when we configured

77
00:03:16,853 --> 00:03:18,682
them with "force-dynamic".

78
00:03:18,752 --> 00:03:21,269
But in this case we set "cache" to

79
00:03:21,269 --> 00:03:23,785
"no-store" in the "fetch" options,

80
00:03:23,859 --> 00:03:25,632
and the result is similar,

81
00:03:25,632 --> 00:03:29,261
because Next.js automatically realized that

82
00:03:29,261 --> 00:03:32,459
if "fetch" returns a new response every time

83
00:03:32,459 --> 00:03:35,027
then the server also needs to generate

84
00:03:35,027 --> 00:03:36,514
each page dynamically,

85
00:03:36,582 --> 00:03:39,258
in order to show the latest data.

86
00:03:39,258 --> 00:03:41,408
Now, let's see how we can use

87
00:03:41,408 --> 00:03:43,113
"revalidation" instead.

88
00:03:43,187 --> 00:03:45,849
We can pass some Next.js-specific

89
00:03:45,849 --> 00:03:47,382
options to "fetch".

90
00:03:47,463 --> 00:03:49,919
That's because Next.js extends

91
00:03:49,919 --> 00:03:52,294
the standard "fetch" function

92
00:03:52,375 --> 00:03:54,888
adding its own caching functionality

93
00:03:54,888 --> 00:03:55,865
on the server.

94
00:03:55,935 --> 00:03:58,727
Here we can set the "revalidate" option,

95
00:03:58,727 --> 00:04:02,093
passing a time interval, like 30 seconds.

96
00:04:02,093 --> 00:04:04,500
So, this works like when configuring

97
00:04:04,500 --> 00:04:05,904
it at the page level.

98
00:04:05,971 --> 00:04:07,342
Let's give it a try,

99
00:04:07,415 --> 00:04:09,650
by making another production build,

100
00:04:10,555 --> 00:04:12,983
which as usual will take a few seconds.

101
00:04:14,702 --> 00:04:17,002
All routes are shown as static,

102
00:04:17,002 --> 00:04:20,123
because they have been generated during the build,

103
00:04:20,123 --> 00:04:22,627
but they should also use revalidation.

104
00:04:22,783 --> 00:04:26,480
Initially the server returns the static pages.

105
00:04:26,480 --> 00:04:29,553
But let's go and change some data in the CMS.

106
00:04:29,729 --> 00:04:32,784
I'll just add "update 1" to this title.

107
00:04:32,784 --> 00:04:34,815
And if we go back to our application,

108
00:04:35,918 --> 00:04:37,992
it will not update immediately,

109
00:04:37,992 --> 00:04:39,926
but if we keep reloading,

110
00:04:39,926 --> 00:04:42,609
at some point the old page will expire,

111
00:04:42,609 --> 00:04:44,535
and you can see that the server

112
00:04:44,535 --> 00:04:45,902
renders a new version,

113
00:04:45,964 --> 00:04:48,663
including all the linked pages.

114
00:04:48,663 --> 00:04:52,083
But in the browser we still see "Subnautica 2",

115
00:04:52,083 --> 00:04:54,667
because, as I explained in the previous video,

116
00:04:54,667 --> 00:04:57,783
the first request that triggers revalidation

117
00:04:57,783 --> 00:04:59,766
still receives the old page.

118
00:04:59,837 --> 00:05:01,418
But if we reload again,

119
00:05:01,418 --> 00:05:03,682
this time we see the new title.

120
00:05:03,682 --> 00:05:06,497
The Reviews page should also be updated.

121
00:05:06,497 --> 00:05:09,131
And the "subnautica-2" page as well.

122
00:05:09,131 --> 00:05:11,956
In the previous video we didn't configure

123
00:05:11,956 --> 00:05:13,955
the ReviewPage to revalidate,

124
00:05:14,023 --> 00:05:16,434
because we assumed we only wanted

125
00:05:16,434 --> 00:05:18,114
to publish new reviews,

126
00:05:18,187 --> 00:05:20,408
but by configuring revalidation

127
00:05:20,408 --> 00:05:22,056
for all fetch requests,

128
00:05:22,128 --> 00:05:24,446
it also applies to this page.

129
00:05:24,446 --> 00:05:26,470
Apart from that, everything works

130
00:05:26,470 --> 00:05:28,127
effectively in the same way

131
00:05:28,188 --> 00:05:30,560
as when we configured revalidation

132
00:05:30,560 --> 00:05:31,815
at the page level.

133
00:05:31,885 --> 00:05:35,260
So, how do you decide which approach to use?

134
00:05:35,260 --> 00:05:37,570
In practice, if you do use "fetch"

135
00:05:37,570 --> 00:05:38,861
in your application

136
00:05:38,929 --> 00:05:41,166
then it's more convenient to set

137
00:05:41,166 --> 00:05:43,193
the "revalidate" option here.

138
00:05:43,263 --> 00:05:45,879
This also provides more flexibility,

139
00:05:45,879 --> 00:05:48,838
because you could set a different interval

140
00:05:48,838 --> 00:05:50,741
on different "fetch" calls,

141
00:05:50,811 --> 00:05:53,896
in case you make multiple API requests

142
00:05:53,896 --> 00:05:55,844
to render the same page.

143
00:05:55,925 --> 00:05:58,977
But not all applications use "fetch".

144
00:05:58,977 --> 00:06:02,149
If you load data from a database for example,

145
00:06:02,149 --> 00:06:04,991
then you'll have to configure revalidation

146
00:06:04,991 --> 00:06:06,750
at the page level instead.