1
00:00:01,020 --> 00:00:02,969
Instructor: So we've got our form on the page.

2
00:00:02,969 --> 00:00:06,780
We can collect a user's email and password.

3
00:00:06,780 --> 00:00:08,790
And whenever the form gets submitted,

4
00:00:08,790 --> 00:00:11,405
we call our event handler, handleformSubmit,

5
00:00:11,405 --> 00:00:13,890
and we console.log the email and password.

6
00:00:13,890 --> 00:00:15,300
So in the entire app so far,

7
00:00:15,300 --> 00:00:16,950
we've been doing a lot of the, you know,

8
00:00:16,950 --> 00:00:18,240
mostly repeat material.

9
00:00:18,240 --> 00:00:20,730
Stuff that we're already pretty darn familiar with.

10
00:00:20,730 --> 00:00:22,680
And we know how to put forms together.

11
00:00:22,680 --> 00:00:23,970
We know how to make components,

12
00:00:23,970 --> 00:00:26,250
we know how to use React Router, all this stuff.

13
00:00:26,250 --> 00:00:27,900
Yeah, pretty straightforward.

14
00:00:27,900 --> 00:00:30,120
So this is where we're starting to go into the realm,

15
00:00:30,120 --> 00:00:31,770
of authentication.

16
00:00:31,770 --> 00:00:33,660
When a user submits the form,

17
00:00:33,660 --> 00:00:37,620
the expectation is that a couple things are going to happen.

18
00:00:37,620 --> 00:00:38,730
We need to validate,

19
00:00:38,730 --> 00:00:41,160
and make sure that the email and password are correct.

20
00:00:41,160 --> 00:00:41,993
You know,

21
00:00:41,993 --> 00:00:44,160
so we need to actually submit them to the server.

22
00:00:44,160 --> 00:00:46,140
And the server's going to tell us, yes they are,

23
00:00:46,140 --> 00:00:49,290
this info is correct, here is a JWT token.

24
00:00:49,290 --> 00:00:51,600
Or no, it's not correct.

25
00:00:51,600 --> 00:00:53,940
You know, email is wrong, password is wrong,

26
00:00:53,940 --> 00:00:55,653
any of a million different things.

27
00:00:56,520 --> 00:00:59,820
So, we need to start to kind of handle this case, you know.

28
00:00:59,820 --> 00:01:01,230
Figure out how we're going to handle,

29
00:01:01,230 --> 00:01:03,780
submitting this email and password to the back end.

30
00:01:04,620 --> 00:01:07,830
Whenever we make, have made a AJAX request in the past,

31
00:01:07,830 --> 00:01:10,110
or any type of request in the past,

32
00:01:10,110 --> 00:01:13,020
we've always stuck that logic into an action creator.

33
00:01:13,020 --> 00:01:14,970
And so that, that's still going to happen here.

34
00:01:14,970 --> 00:01:16,440
You know, we're still going to use an action creator,

35
00:01:16,440 --> 00:01:17,880
to make the request.

36
00:01:17,880 --> 00:01:20,100
But the very important thing to note is that,

37
00:01:20,100 --> 00:01:22,920
in every single time that we've had an action creator

38
00:01:22,920 --> 00:01:27,210
so far, there's always been kind of a singular action,

39
00:01:27,210 --> 00:01:30,750
or single singular flow that's come out of that.

40
00:01:30,750 --> 00:01:33,480
There's been no branching logic whatsoever.

41
00:01:33,480 --> 00:01:35,340
So we've never really had to handle the case,

42
00:01:35,340 --> 00:01:39,300
in which say, a user posted a email and password,

43
00:01:39,300 --> 00:01:42,030
and the password was incorrect.

44
00:01:42,030 --> 00:01:43,980
We've only ever handled the case, you know,

45
00:01:43,980 --> 00:01:46,200
where everything worked as intended.

46
00:01:46,200 --> 00:01:47,760
And so, at this point in time,

47
00:01:47,760 --> 00:01:48,810
we need to start thinking about,

48
00:01:48,810 --> 00:01:50,523
how we deal with air handling.

49
00:01:52,500 --> 00:01:55,230
So let's look at a diagram that illustrates the flow

50
00:01:55,230 --> 00:01:56,670
that a user is going to go through,

51
00:01:56,670 --> 00:01:58,983
once they submit an email and a password.

52
00:02:00,000 --> 00:02:00,930
The very top.

53
00:02:00,930 --> 00:02:01,763
We start off,

54
00:02:01,763 --> 00:02:05,250
where a user is going to submit their email and password.

55
00:02:05,250 --> 00:02:07,980
That info will be submitted to an action creator,

56
00:02:07,980 --> 00:02:09,780
and the action creator is going to submit that,

57
00:02:09,780 --> 00:02:11,460
to our server.

58
00:02:11,460 --> 00:02:13,050
The server's then going to decide,

59
00:02:13,050 --> 00:02:14,970
whether or not the info is correct.

60
00:02:14,970 --> 00:02:16,470
And so that can be, you know,

61
00:02:16,470 --> 00:02:18,780
is this email exist in the database,

62
00:02:18,780 --> 00:02:20,190
is the password correct?

63
00:02:20,190 --> 00:02:22,200
You know, all those kind of good authentication checks

64
00:02:22,200 --> 00:02:23,900
that we've already wired together.

65
00:02:25,260 --> 00:02:27,900
Depending on whether or not the info is correct,

66
00:02:27,900 --> 00:02:30,840
we get two completely different scenarios.

67
00:02:30,840 --> 00:02:34,290
If the info is not correct, all we want to do,

68
00:02:34,290 --> 00:02:35,910
the only thing we want to do,

69
00:02:35,910 --> 00:02:38,133
is show an error message to the user.

70
00:02:38,970 --> 00:02:42,390
But in the case, that the info is correct,

71
00:02:42,390 --> 00:02:45,120
and the server returns a JWT token,

72
00:02:45,120 --> 00:02:48,300
then an entire range of different things are going to occur

73
00:02:48,300 --> 00:02:49,950
inside of our application.

74
00:02:49,950 --> 00:02:53,040
We need to redirect our user to /feature, you know,

75
00:02:53,040 --> 00:02:55,860
that kind of protected route that we discussed earlier,

76
00:02:55,860 --> 00:02:57,240
in the wire frames.

77
00:02:57,240 --> 00:03:00,240
We need to update our application state,

78
00:03:00,240 --> 00:03:02,820
to reflect that the user is currently authenticated.

79
00:03:02,820 --> 00:03:03,653
And third,

80
00:03:03,653 --> 00:03:05,520
we need to save the token that gets returned

81
00:03:05,520 --> 00:03:06,353
from the server.

82
00:03:06,353 --> 00:03:08,700
So there are three completely different,

83
00:03:08,700 --> 00:03:13,700
very separate actions, or kind of side effects that occur,

84
00:03:13,770 --> 00:03:16,380
when a user is successfully authenticated.

85
00:03:16,380 --> 00:03:20,370
When they successfully provide email and password.

86
00:03:20,370 --> 00:03:23,130
So not only do we have this kind of branching logic,

87
00:03:23,130 --> 00:03:24,930
inside of our action creator.

88
00:03:24,930 --> 00:03:26,850
In the positive case here,

89
00:03:26,850 --> 00:03:30,120
we also have multiple side effects of our application.

90
00:03:30,120 --> 00:03:31,500
So you can really juxtapose that,

91
00:03:31,500 --> 00:03:34,860
to all the other action creators that we've created before.

92
00:03:34,860 --> 00:03:38,160
Where it was like, one action creator you would call it,

93
00:03:38,160 --> 00:03:41,190
it would return a single action,

94
00:03:41,190 --> 00:03:44,000
and then a single reducer would pick up that single action,

95
00:03:44,000 --> 00:03:46,320
to make a single change in the app.

96
00:03:46,320 --> 00:03:48,420
So we're now starting to go into the realm of,

97
00:03:48,420 --> 00:03:49,253
one action creator.

98
00:03:49,253 --> 00:03:52,110
It's going to result in several different changes,

99
00:03:52,110 --> 00:03:54,210
inside of our application.

100
00:03:54,210 --> 00:03:56,880
We want to redirect the user, update our state,

101
00:03:56,880 --> 00:03:57,930
and save our token.

102
00:03:57,930 --> 00:04:00,453
So three separate and distinct things.

103
00:04:01,710 --> 00:04:04,500
So this is the big challenge behind authentication,

104
00:04:04,500 --> 00:04:06,510
especially in a Redux application.

105
00:04:06,510 --> 00:04:08,580
It really tips the entire Redux model,

106
00:04:08,580 --> 00:04:10,440
kind of in its on its head a little bit, you know?

107
00:04:10,440 --> 00:04:13,770
It's kind of, very different than a lot of the more,

108
00:04:13,770 --> 00:04:16,620
plain, vanilla interactions that we've been used to before,

109
00:04:16,620 --> 00:04:19,170
where we were say, creating resources,

110
00:04:19,170 --> 00:04:21,930
or editing resources, or deleting resources.

111
00:04:21,930 --> 00:04:23,040
Anything like that.

112
00:04:23,040 --> 00:04:24,720
JBT, or excuse me, authentication,

113
00:04:24,720 --> 00:04:26,910
starts to really kind of throw a wrench

114
00:04:26,910 --> 00:04:28,113
into that whole plan.

115
00:04:29,520 --> 00:04:30,900
So enough talking about the challenge,

116
00:04:30,900 --> 00:04:33,273
let's actually tackle it, so to speak.

117
00:04:34,380 --> 00:04:35,610
As we saw in the diagram,

118
00:04:35,610 --> 00:04:37,560
we definitely need an action creator.

119
00:04:37,560 --> 00:04:40,470
And so I think that, definitely the best place to start,

120
00:04:40,470 --> 00:04:42,480
is to put that action creator together.

121
00:04:42,480 --> 00:04:44,730
Just something that we can actually call,

122
00:04:44,730 --> 00:04:46,500
and probably, you know, make our request,

123
00:04:46,500 --> 00:04:48,480
and figure out, okay, we made the request,

124
00:04:48,480 --> 00:04:50,550
and you know, now what do we do?

125
00:04:50,550 --> 00:04:51,540
So, you know, let's kind of put,

126
00:04:51,540 --> 00:04:54,540
that next little bit of logic together,

127
00:04:54,540 --> 00:04:56,670
and then we'll worry about how we,

128
00:04:56,670 --> 00:04:59,130
make several different changes to our application,

129
00:04:59,130 --> 00:05:00,903
when this action creator is called.

130
00:05:02,070 --> 00:05:03,330
So for any action creator,

131
00:05:03,330 --> 00:05:05,940
we always start off by making our types file,

132
00:05:05,940 --> 00:05:07,590
and then creating our action creator

133
00:05:07,590 --> 00:05:11,730
inside of our index.js file, in the actions directory.

134
00:05:11,730 --> 00:05:15,150
Let's kind of go into a little bit of a different path,

135
00:05:15,150 --> 00:05:16,470
than we have in the past,

136
00:05:16,470 --> 00:05:18,630
where we would first create a type.

137
00:05:18,630 --> 00:05:22,230
This time around, let's first make our action creator.

138
00:05:22,230 --> 00:05:24,180
And we'll see why in just a little bit.

139
00:05:25,770 --> 00:05:29,130
So inside of index.js, inside the actions directory,

140
00:05:29,130 --> 00:05:33,553
I'm going to create a new function, called, signInUser.

141
00:05:34,560 --> 00:05:36,690
And I'm going to assume that this is going to be called,

142
00:05:36,690 --> 00:05:38,700
with an email,

143
00:05:38,700 --> 00:05:39,633
and a password.

144
00:05:42,300 --> 00:05:44,730
So whenever this action creator is called,

145
00:05:44,730 --> 00:05:46,980
the assumption is we're going to pass in specifically,

146
00:05:46,980 --> 00:05:49,890
an object, that contains an email property,

147
00:05:49,890 --> 00:05:51,273
and a password property.

148
00:05:52,140 --> 00:05:52,973
Okay?

149
00:05:54,180 --> 00:05:57,540
So, inside this action creator, we want to, you know,

150
00:05:57,540 --> 00:05:58,890
definitely do a couple different things.

151
00:05:58,890 --> 00:06:00,420
We want to,

152
00:06:00,420 --> 00:06:02,610
submit email,

153
00:06:02,610 --> 00:06:04,860
password to,

154
00:06:04,860 --> 00:06:05,793
the server.

155
00:06:08,820 --> 00:06:10,760
If request is good...

156
00:06:12,570 --> 00:06:14,250
We need to,

157
00:06:14,250 --> 00:06:15,483
update state,

158
00:06:17,250 --> 00:06:18,723
to indicate,

159
00:06:21,030 --> 00:06:22,503
users authenticated.

160
00:06:23,730 --> 00:06:25,620
We need to save,

161
00:06:25,620 --> 00:06:27,510
the JWT token,

162
00:06:27,510 --> 00:06:30,540
so that users can make authenticated requests in the future.

163
00:06:30,540 --> 00:06:32,910
Remember, that's the entire point of the JWT token.

164
00:06:32,910 --> 00:06:34,380
It's how we figure out,

165
00:06:34,380 --> 00:06:36,870
or it's how we make follow-up requests to the back end,

166
00:06:36,870 --> 00:06:38,040
that are authenticated.

167
00:06:38,040 --> 00:06:41,820
And finally, we need to redirect,

168
00:06:41,820 --> 00:06:43,893
to the route /feature.

169
00:06:45,720 --> 00:06:48,300
And again, this kind of redirect right here,

170
00:06:48,300 --> 00:06:51,990
to /feature, is just very particular to our application.

171
00:06:51,990 --> 00:06:53,130
If you're making a different app,

172
00:06:53,130 --> 00:06:54,930
that serves something else, you can, you know.

173
00:06:54,930 --> 00:06:57,693
This will be very easily customizable in the future.

174
00:06:58,800 --> 00:07:00,420
And then we also need to handle the case,

175
00:07:00,420 --> 00:07:02,970
if request is bad.

176
00:07:02,970 --> 00:07:03,840
What do we do then?

177
00:07:03,840 --> 00:07:05,460
If the request is bad,

178
00:07:05,460 --> 00:07:10,080
we need to somehow show an error to the user.

179
00:07:10,080 --> 00:07:11,040
Okay?

180
00:07:11,040 --> 00:07:14,220
So again, this really starts to highlight how different,

181
00:07:14,220 --> 00:07:15,390
this action creator is,

182
00:07:15,390 --> 00:07:17,940
compared to the ones that we've dealt with in the past.

183
00:07:17,940 --> 00:07:19,410
In the past it's always been,

184
00:07:19,410 --> 00:07:22,950
make the AJAX request, return an action, that's it.

185
00:07:22,950 --> 00:07:23,823
Nothing else.

186
00:07:24,722 --> 00:07:26,550
No other action here, no other side effects,

187
00:07:26,550 --> 00:07:28,920
just a very straightforward approach.

188
00:07:28,920 --> 00:07:31,950
But this time around, not only do we have branching logic,

189
00:07:31,950 --> 00:07:34,380
we also have several different things

190
00:07:34,380 --> 00:07:37,473
that we want to achieve, when the request succeeds.

191
00:07:38,970 --> 00:07:41,730
So, for all the requests we've made so far,

192
00:07:41,730 --> 00:07:44,490
we've been using the library called redux-promise.

193
00:07:44,490 --> 00:07:46,650
Where we would just create a request,

194
00:07:46,650 --> 00:07:48,030
return it on the action,

195
00:07:48,030 --> 00:07:50,040
and then our data would kind of magically show up

196
00:07:50,040 --> 00:07:51,600
inside the reducer.

197
00:07:51,600 --> 00:07:54,240
So that is definitely, probably going to kind of not be,

198
00:07:54,240 --> 00:07:55,860
exactly the approach we want here.

199
00:07:55,860 --> 00:07:57,450
We want something with a little bit more power,

200
00:07:57,450 --> 00:07:58,440
a little bit more oomph.

201
00:07:58,440 --> 00:08:01,170
Something that gives us a little bit more flexibility,

202
00:08:01,170 --> 00:08:03,570
to kind of dispatch different actions,

203
00:08:03,570 --> 00:08:06,570
or, take different, you know, responses,

204
00:08:06,570 --> 00:08:08,700
or handle this data differently,

205
00:08:08,700 --> 00:08:11,070
depending on what comes back from the server.

206
00:08:11,070 --> 00:08:14,400
So again, that's the big challenge that we need to fix here.

207
00:08:14,400 --> 00:08:17,970
Let's continue talking about this, the problem,

208
00:08:17,970 --> 00:08:19,590
and what we're going to do to solve it,

209
00:08:19,590 --> 00:08:20,913
inside the next section.