1
00:00:02,000 --> 00:00:04,000
So we did learn about get static props,

2
00:00:04,000 --> 00:00:08,000
and how we can use it to prepare data on the server side

3
00:00:08,000 --> 00:00:12,000
so to say, for pre-rendering the page.

4
00:00:12,000 --> 00:00:14,000
However, when I say on the server side,

5
00:00:14,000 --> 00:00:16,000
that's only partially correct.

6
00:00:16,000 --> 00:00:20,000
We can execute server-side code here, but in the end

7
00:00:20,000 --> 00:00:23,000
the code will not run on the actual server, which serves

8
00:00:23,000 --> 00:00:26,000
our application, instead it runs on our machine

9
00:00:26,000 --> 00:00:29,000
when the page is built when the application

10
00:00:29,000 --> 00:00:31,000
is built with next.

11
00:00:31,000 --> 00:00:34,000
So in the end, when you run, NPM run build.

12
00:00:34,000 --> 00:00:39,000
When you execute that prepared script here,

13
00:00:39,000 --> 00:00:44,000
which executes next build, then this code is executed.

14
00:00:44,000 --> 00:00:49,000
Now that's still good because since we have no JS installed

15
00:00:49,000 --> 00:00:51,000
all that node JS code does work here.

16
00:00:51,000 --> 00:00:56,000
So that's perfect, but it has one potential downside.

17
00:00:56,000 --> 00:01:01,000
What if you have data that changes frequently?

18
00:01:01,000 --> 00:01:05,000
Because I mean, pre-generating the pages sounds great

19
00:01:05,000 --> 00:01:08,000
if you're building something fairly static.

20
00:01:08,000 --> 00:01:10,000
If you're building a blog, where data

21
00:01:10,000 --> 00:01:13,000
doesn't change too often, then of course,

22
00:01:13,000 --> 00:01:15,000
whenever you add a new blog post,

23
00:01:15,000 --> 00:01:18,000
you can just pre-generate your project again,

24
00:01:18,000 --> 00:01:21,000
you can run NPM run build again,

25
00:01:21,000 --> 00:01:24,000
and deploy the updated project.

26
00:01:24,000 --> 00:01:25,000
So that would work.

27
00:01:25,000 --> 00:01:29,000
But if you have data that changes more frequently,

28
00:01:29,000 --> 00:01:31,000
if we add a fourth product here

29
00:01:31,000 --> 00:01:35,000
after the page was deployed, then we have to rebuild

30
00:01:35,000 --> 00:01:38,000
and redeploy the page all the time.

31
00:01:38,000 --> 00:01:43,000
And that doesn't sound like a great thing to do.

32
00:01:43,000 --> 00:01:46,000
Well, Next.js also has solutions for this.

33
00:01:46,000 --> 00:01:51,000
Solution number one is that you do pre-build your page,

34
00:01:51,000 --> 00:01:55,000
but then you still include standard react code

35
00:01:55,000 --> 00:01:58,000
in your react components, where you use, use effect

36
00:01:58,000 --> 00:02:03,000
for then fetching updated data from a server.

37
00:02:03,000 --> 00:02:06,000
So you would always serve back a page

38
00:02:06,000 --> 00:02:08,000
with some pre-rendered data,

39
00:02:08,000 --> 00:02:11,000
but that data might be outdated.

40
00:02:11,000 --> 00:02:14,000
So you fetched a latest data in the background

41
00:02:14,000 --> 00:02:19,000
and then update the loaded page after that data arrived.

42
00:02:19,000 --> 00:02:21,000
That's a pattern you could implement.

43
00:02:21,000 --> 00:02:25,000
Then you at least chose something to your users,

44
00:02:25,000 --> 00:02:27,000
but it might be a bit outdated,

45
00:02:27,000 --> 00:02:29,000
but that's why you're fetching data in the background,

46
00:02:29,000 --> 00:02:32,000
so that you can update the page

47
00:02:32,000 --> 00:02:35,000
with the latest data once you got that.

48
00:02:35,000 --> 00:02:38,000
That might be a perfectly valid pattern,

49
00:02:38,000 --> 00:02:42,000
but there is an alternative which often is better.

50
00:02:42,000 --> 00:02:46,000
This get static props function, as I mentioned does execute

51
00:02:46,000 --> 00:02:50,000
when you build your project with next build,

52
00:02:50,000 --> 00:02:52,000
so with this build script.

53
00:02:52,000 --> 00:02:54,000
Well, that's not entirely true.

54
00:02:54,000 --> 00:02:58,000
It does execute there, but that is not necessarily

55
00:02:58,000 --> 00:03:01,000
the only time it executes.

56
00:03:01,000 --> 00:03:04,000
Instead, Next.js has a built in feature,

57
00:03:04,000 --> 00:03:09,000
which is called incremental static generation.

58
00:03:09,000 --> 00:03:11,000
It means that you don't just generate

59
00:03:11,000 --> 00:03:14,000
your page statically once at build time,

60
00:03:14,000 --> 00:03:17,000
but that it's continuously updated

61
00:03:17,000 --> 00:03:22,000
even after deployment without you re-deploying it.

62
00:03:22,000 --> 00:03:25,000
So you pre-generate a page, but then you can also

63
00:03:25,000 --> 00:03:29,000
tell Next.js that a given page should be re-generated again

64
00:03:29,000 --> 00:03:34,000
for every incoming request at most every X seconds.

65
00:03:35,000 --> 00:03:38,000
So every 60 seconds, for example.

66
00:03:38,000 --> 00:03:41,000
That means that if a request is made

67
00:03:41,000 --> 00:03:46,000
for a certain page and it's, let's say less than 60 seconds

68
00:03:46,000 --> 00:03:50,000
since it was last re-generated, the existing page

69
00:03:50,000 --> 00:03:52,000
would be served to the visitor.

70
00:03:52,000 --> 00:03:55,000
But if it's past those 60 seconds

71
00:03:55,000 --> 00:03:58,000
and the amount of seconds of course is up to you,

72
00:03:58,000 --> 00:04:02,000
then this page would be pre-generated on the server instead.

73
00:04:02,000 --> 00:04:05,000
So that means that you either serve the old page

74
00:04:05,000 --> 00:04:09,000
if it's not that old yet, or you serve the latest page

75
00:04:09,000 --> 00:04:13,000
and brand new page, which was generated again

76
00:04:13,000 --> 00:04:16,000
on the server otherwise.

77
00:04:16,000 --> 00:04:19,000
And if that page was pre-generated again

78
00:04:19,000 --> 00:04:22,000
on the server, because it was outdated,

79
00:04:22,000 --> 00:04:24,000
then this newly generated page

80
00:04:24,000 --> 00:04:28,000
will replace the existing old page on the server.

81
00:04:28,000 --> 00:04:31,000
It will be cashed and future visitors

82
00:04:31,000 --> 00:04:35,000
will see that re-generated page instead.

83
00:04:35,000 --> 00:04:37,000
Until 60 seconds passed again,

84
00:04:37,000 --> 00:04:40,000
and then new page is pre-generated again.

85
00:04:40,000 --> 00:04:44,000
So you can have ongoing pre-rendering on the server

86
00:04:44,000 --> 00:04:47,000
for incoming requests.

87
00:04:47,000 --> 00:04:52,000
And all you need to do to unlock this is in the object,

88
00:04:52,000 --> 00:04:55,000
which you return in get static props.

89
00:04:55,000 --> 00:04:57,000
You don't just return props,

90
00:04:57,000 --> 00:05:01,000
but you also add a second key, which is called revalidate.

91
00:05:02,000 --> 00:05:05,000
And as a value, you set a number a year,

92
00:05:05,000 --> 00:05:09,000
which is the time in seconds that Next.js

93
00:05:09,000 --> 00:05:13,000
should wait until it re-generates this page.

94
00:05:13,000 --> 00:05:17,000
So for example, if I enter 10 here, we would tell Next.js

95
00:05:17,000 --> 00:05:20,000
that for every incoming request to this page,

96
00:05:20,000 --> 00:05:23,000
it should be re-generated unless,

97
00:05:23,000 --> 00:05:28,000
it's less than 10 seconds ago that it was last re-generated.

98
00:05:29,000 --> 00:05:33,000
So it's recreated at most once every 10 seconds.

99
00:05:33,000 --> 00:05:36,000
And of course the higher this number is,

100
00:05:36,000 --> 00:05:39,000
the less this page will be re-generated.

101
00:05:39,000 --> 00:05:42,000
And it's totally up to you which value you want here.

102
00:05:42,000 --> 00:05:45,000
It will of course depend on which kind of application

103
00:05:45,000 --> 00:05:47,000
you're building.

104
00:05:47,000 --> 00:05:50,000
For a highly dynamic page where content changes

105
00:05:50,000 --> 00:05:53,000
all the time, you want a very low value,

106
00:05:53,000 --> 00:05:56,000
maybe just one second.

107
00:05:56,000 --> 00:05:59,000
For pages where the content is less dynamic,

108
00:05:59,000 --> 00:06:02,000
maybe 10 minutes is enough.

109
00:06:02,000 --> 00:06:05,000
So that is then really something you have to decide.

110
00:06:06,000 --> 00:06:10,000
Now during development, the page will be re-generated

111
00:06:10,000 --> 00:06:14,000
for every request, no matter what you enter here.

112
00:06:14,000 --> 00:06:17,000
So with the development server, we will always see

113
00:06:17,000 --> 00:06:19,000
the latest page with the latest data,

114
00:06:19,000 --> 00:06:22,000
and this will always run again.

115
00:06:22,000 --> 00:06:25,000
But in production this number will matter.

116
00:06:25,000 --> 00:06:30,000
So here, if I add, re-generating here in a console log,

117
00:06:35,000 --> 00:06:39,000
instead of get static props, if I now rerun

118
00:06:39,000 --> 00:06:44,000
the development server, we will see here in this terminal,

119
00:06:44,000 --> 00:06:47,000
since that is server side terminal, so to say,

120
00:06:47,000 --> 00:06:51,000
we see re-generating, because I started the Def server.

121
00:06:51,000 --> 00:06:53,000
So that's equivalent to the build process.

122
00:06:53,000 --> 00:06:56,000
It was now pre-generated.

123
00:06:56,000 --> 00:06:59,000
But if I now visit this page by reloading, for example

124
00:06:59,000 --> 00:07:02,000
we see this again, because as I just said,

125
00:07:02,000 --> 00:07:06,000
during development, the revalidate number doesn't matter.

126
00:07:06,000 --> 00:07:08,000
It will re-generate it every time.

127
00:07:08,000 --> 00:07:10,000
In production it will matter,

128
00:07:10,000 --> 00:07:13,000
and then you have the best of both worlds.

129
00:07:13,000 --> 00:07:15,000
You have a pre-rendered page,

130
00:07:15,000 --> 00:07:18,000
which then still is updated after deployment,

131
00:07:18,000 --> 00:07:20,000
just as defined by you.