1
00:00:00,440 --> 00:00:02,670
-: In the last section, we added a whole bunch

2
00:00:02,670 --> 00:00:04,470
of code without being really clear

3
00:00:04,470 --> 00:00:06,660
about exactly what we were doing and why.

4
00:00:06,660 --> 00:00:08,970
So I want to take a second just to clarify

5
00:00:08,970 --> 00:00:11,190
on exactly what we were doing in the last section

6
00:00:11,190 --> 00:00:13,530
and all the different code that we added.

7
00:00:13,530 --> 00:00:14,970
So I'm gonna pull a diagram on the screen

8
00:00:14,970 --> 00:00:15,960
very similar to one that we

9
00:00:15,960 --> 00:00:17,400
were looking at earlier.

10
00:00:17,400 --> 00:00:19,740
It's just illustrating what we want to do

11
00:00:19,740 --> 00:00:21,330
when the user enters the correct

12
00:00:21,330 --> 00:00:23,130
authentication info.

13
00:00:23,130 --> 00:00:25,320
So, if they do not enter the correct info,

14
00:00:25,320 --> 00:00:27,330
we want to show them an error message

15
00:00:27,330 --> 00:00:29,340
which we're going to eventually do

16
00:00:29,340 --> 00:00:30,990
by updating the error piece of

17
00:00:30,990 --> 00:00:33,480
state inside of our auth reducer.

18
00:00:33,480 --> 00:00:35,430
Then our sign-in form can just show

19
00:00:35,430 --> 00:00:36,540
that error message that we

20
00:00:36,540 --> 00:00:37,530
get back from the server.

21
00:00:37,530 --> 00:00:39,393
And poof, there's our error handling.

22
00:00:40,560 --> 00:00:42,480
In the case that a user does enter

23
00:00:42,480 --> 00:00:44,790
the correct information, we want to

24
00:00:44,790 --> 00:00:46,770
dispatch an action to flip the

25
00:00:46,770 --> 00:00:49,140
authenticated piece of state to true.

26
00:00:49,140 --> 00:00:50,790
And so that's what what's gonna tell the rest

27
00:00:50,790 --> 00:00:52,080
of our application,

28
00:00:52,080 --> 00:00:54,300
'Hey, they just enter the correct info here.

29
00:00:54,300 --> 00:00:56,190
They are currently authenticated.

30
00:00:56,190 --> 00:00:57,930
Everything is good to go.'

31
00:00:57,930 --> 00:01:01,320
Notice that we don't really have to store the JWT

32
00:01:01,320 --> 00:01:03,630
on our application state.

33
00:01:03,630 --> 00:01:04,890
No part of our application

34
00:01:04,890 --> 00:01:07,290
really needs to make use of the JWT.

35
00:01:07,290 --> 00:01:10,380
The only thing that really does is Axios when

36
00:01:10,380 --> 00:01:12,330
we go to make an ajax request

37
00:01:12,330 --> 00:01:14,010
cuz remember we set up our servers

38
00:01:14,010 --> 00:01:16,500
authentication to work by looking for

39
00:01:16,500 --> 00:01:19,230
JWT in the header of any request.

40
00:01:19,230 --> 00:01:21,815
So we don't really need to store the JWT inside

41
00:01:21,815 --> 00:01:24,069
of our application state.

42
00:01:24,069 --> 00:01:27,150
Instead, we just store this Boolean that says

43
00:01:27,150 --> 00:01:29,550
whether or not they are currently authenticated.

44
00:01:30,840 --> 00:01:33,060
The second thing we need to do is navigate the

45
00:01:33,060 --> 00:01:34,980
user to slash feature.

46
00:01:34,980 --> 00:01:36,630
And finally we need to,

47
00:01:36,630 --> 00:01:38,130
and this is the part we haven't done yet,

48
00:01:38,130 --> 00:01:40,650
we need to actually save the JWT token

49
00:01:40,650 --> 00:01:42,150
for future requests.

50
00:01:42,150 --> 00:01:43,500
And we're definitely gonna talk about, you know

51
00:01:43,500 --> 00:01:44,880
you might be thinking, 'Hey Steven

52
00:01:44,880 --> 00:01:48,300
can't people just kind of go into their JavaScript console

53
00:01:48,300 --> 00:01:50,850
and somehow flip authenticated to true?'

54
00:01:50,850 --> 00:01:53,040
And the answer to that is yes, absolutely.

55
00:01:53,040 --> 00:01:53,910
And you might be thinking,

56
00:01:53,910 --> 00:01:55,577
'Isn't that a security hole?'

57
00:01:55,577 --> 00:01:57,390
Well, uh, not, not quite

58
00:01:57,390 --> 00:01:58,500
but that is a topic that we will

59
00:01:58,500 --> 00:01:59,610
talk about very soon.

60
00:01:59,610 --> 00:02:01,023
So hold that thought.

61
00:02:02,190 --> 00:02:03,690
So again, we need to accomplish these

62
00:02:03,690 --> 00:02:04,590
three features here

63
00:02:04,590 --> 00:02:06,900
or these three kind of actions.

64
00:02:06,900 --> 00:02:09,330
Let's walk through the code that we added

65
00:02:09,330 --> 00:02:11,640
in the last section to dispatch the action to

66
00:02:11,640 --> 00:02:14,193
flip the authenticated piece of state to true.

67
00:02:16,020 --> 00:02:18,540
So back in the code editor, I'm not gonna go

68
00:02:18,540 --> 00:02:20,790
through the code in the order that we added it.

69
00:02:20,790 --> 00:02:22,530
Instead I'm gonna go through in the order

70
00:02:22,530 --> 00:02:25,230
that the code is actually going to execute.

71
00:02:25,230 --> 00:02:26,790
So whenever we call the sign-in

72
00:02:26,790 --> 00:02:29,520
user action creator, we're going to return

73
00:02:29,520 --> 00:02:31,860
a function that's going to be automatically

74
00:02:31,860 --> 00:02:34,740
called by the redux thunk middleware.

75
00:02:34,740 --> 00:02:36,420
And the redux thunk middleware is gonna

76
00:02:36,420 --> 00:02:39,093
call that function with the dispatch method.

77
00:02:40,710 --> 00:02:42,480
We make our ajax request

78
00:02:42,480 --> 00:02:44,670
attempting to sign our user in.

79
00:02:44,670 --> 00:02:46,380
If the request is successful,

80
00:02:46,380 --> 00:02:49,860
and so if it returns a like 200 in response

81
00:02:49,860 --> 00:02:53,220
or 204 depending on how our server is responding

82
00:02:53,220 --> 00:02:55,830
we're gonna hit, hit our then case.

83
00:02:55,830 --> 00:02:59,070
So everything inside of our then case means hey

84
00:02:59,070 --> 00:03:01,380
the user was just successfully authenticated

85
00:03:01,380 --> 00:03:02,213
on the back end.

86
00:03:02,213 --> 00:03:03,960
So we need to respond to that by

87
00:03:03,960 --> 00:03:06,393
doing our three very good things.

88
00:03:07,680 --> 00:03:09,870
The first thing that we're gonna do is update our

89
00:03:09,870 --> 00:03:11,700
state to indicate that the user

90
00:03:11,700 --> 00:03:13,740
is currently authenticated.

91
00:03:13,740 --> 00:03:16,170
So we immediately dispatch an action

92
00:03:16,170 --> 00:03:19,140
of type auth user.

93
00:03:19,140 --> 00:03:21,690
This is redux thunk in action right here.

94
00:03:21,690 --> 00:03:23,520
Again, we've got direct access

95
00:03:23,520 --> 00:03:24,690
to the dispatch method.

96
00:03:24,690 --> 00:03:26,940
It is the all powerful function

97
00:03:26,940 --> 00:03:29,116
within redux that gives us total control

98
00:03:29,116 --> 00:03:30,810
over the redux pipeline.

99
00:03:30,810 --> 00:03:33,450
If we call it and we pass an action in

100
00:03:33,450 --> 00:03:35,340
that is the exact same as when we

101
00:03:35,340 --> 00:03:38,100
had previously been calling an action creator

102
00:03:38,100 --> 00:03:41,730
and returning just a plain object as an action.

103
00:03:41,730 --> 00:03:43,860
In this case, however,

104
00:03:43,860 --> 00:03:44,910
we don't really get the benefit

105
00:03:44,910 --> 00:03:47,760
of being able to kind of return an action

106
00:03:47,760 --> 00:03:48,960
from inside this promise in

107
00:03:48,960 --> 00:03:50,550
any meaningful way, right?

108
00:03:50,550 --> 00:03:52,170
If I return something in here,

109
00:03:52,170 --> 00:03:55,230
if I return an object, it's not gonna end

110
00:03:55,230 --> 00:03:57,930
up being what gets returned from sign-in user.

111
00:03:57,930 --> 00:04:01,053
No. The function gets returned from sign-in user.

112
00:04:02,580 --> 00:04:05,580
So instead at this point, to dispatch an action

113
00:04:05,580 --> 00:04:07,830
we have to call the dispatch method directly.

114
00:04:09,030 --> 00:04:11,550
We set up our auth reducer inside

115
00:04:11,550 --> 00:04:13,380
of auth reducer JS

116
00:04:13,380 --> 00:04:17,043
to handle an action of type auth user right here.

117
00:04:18,232 --> 00:04:20,970
Whenever we got that action of type auth user,

118
00:04:20,970 --> 00:04:23,910
we flipped our authenticated flag to true.

119
00:04:23,910 --> 00:04:27,120
We also set up a case in here to handle

120
00:04:27,120 --> 00:04:30,330
unauthenticated user or helping them log out

121
00:04:30,330 --> 00:04:33,093
by flipping that authenticated flag to false.

122
00:04:35,310 --> 00:04:37,830
Going back over to our action creators file,

123
00:04:37,830 --> 00:04:39,720
we've not yet done the logic for

124
00:04:39,720 --> 00:04:41,940
saving our GWT token.

125
00:04:41,940 --> 00:04:42,930
So we're gonna handle that

126
00:04:42,930 --> 00:04:44,640
inside the next section.

127
00:04:44,640 --> 00:04:46,710
The third thing that's happening is we are

128
00:04:46,710 --> 00:04:49,560
redirecting our user to the route slash

129
00:04:49,560 --> 00:04:51,120
feature right here.

130
00:04:51,120 --> 00:04:52,830
And so we are doing that navigation

131
00:04:52,830 --> 00:04:55,080
by using the browser history object

132
00:04:55,080 --> 00:04:58,230
and pushing a new route onto the stack.

133
00:04:58,230 --> 00:05:01,890
So this push method right here is what does some forcible

134
00:05:01,890 --> 00:05:05,760
or programmatic navigation for our users.

135
00:05:05,760 --> 00:05:08,880
Okay, so nice little quick review.

136
00:05:08,880 --> 00:05:11,010
Again, I know that we're kind of approaching this

137
00:05:11,010 --> 00:05:12,510
on many different fronts at once

138
00:05:12,510 --> 00:05:13,980
but unfortunately it's kind of a

139
00:05:13,980 --> 00:05:16,650
unavoidable aspect of authentication

140
00:05:16,650 --> 00:05:18,540
to have to kind of juggle a bunch of

141
00:05:18,540 --> 00:05:20,790
different topics at the same time.

142
00:05:20,790 --> 00:05:23,160
So in the next section we're gonna continue being

143
00:05:23,160 --> 00:05:24,780
productive, writing some code.

144
00:05:24,780 --> 00:05:27,120
We need to save our JWT token.

145
00:05:27,120 --> 00:05:28,710
We also need to handle,

146
00:05:28,710 --> 00:05:30,120
whenever our request is bad,

147
00:05:30,120 --> 00:05:31,950
we need to show an error to our user.

148
00:05:31,950 --> 00:05:34,740
So we'll take care of that very soon as well.

149
00:05:34,740 --> 00:05:36,120
So let's continue in the next section

150
00:05:36,120 --> 00:05:38,070
by working with our JWT token.

151
00:05:38,070 --> 00:05:39,020
I'll see you there.