1 00:00:00,660 --> 00:00:02,009 -: Our applications definitely still 2 00:00:02,009 --> 00:00:04,200 has one big deficiency to it. 3 00:00:04,200 --> 00:00:06,120 If I click the sign in link 4 00:00:06,120 --> 00:00:07,360 and then I sign in 5 00:00:09,900 --> 00:00:12,960 I can now get access to my feature route 6 00:00:12,960 --> 00:00:15,840 and I can even see inside of my console 7 00:00:15,840 --> 00:00:18,690 I can check local storage for my token. 8 00:00:18,690 --> 00:00:21,540 And yep, sure enough, my JWT token is definitely here 9 00:00:21,540 --> 00:00:23,220 so I'm definitely considered to be logged in 10 00:00:23,220 --> 00:00:24,930 at this point in time. 11 00:00:24,930 --> 00:00:26,670 Now let's do something a little bit interesting 12 00:00:26,670 --> 00:00:28,170 something that definitely our users 13 00:00:28,170 --> 00:00:29,460 will be doing all the time. 14 00:00:29,460 --> 00:00:31,100 I'm gonna refresh the page 15 00:00:31,100 --> 00:00:34,350 and all of a sudden I get kicked back to the root route 16 00:00:34,350 --> 00:00:37,410 and my header has now changed to say sign in and sign up. 17 00:00:37,410 --> 00:00:39,690 So I'm definitely no longer considered 18 00:00:39,690 --> 00:00:42,958 to be authenticated inside our application. 19 00:00:42,958 --> 00:00:44,292 Let's see, I still got the token around 20 00:00:44,292 --> 00:00:47,280 so I kinda have a reasonable expectation 21 00:00:47,280 --> 00:00:48,630 that I should be signed in. 22 00:00:48,630 --> 00:00:50,430 But our application really has absolutely 23 00:00:50,430 --> 00:00:53,110 no logic to say, "Hey, if the user has a token 24 00:00:53,110 --> 00:00:55,320 they're probably still authenticated. 25 00:00:55,320 --> 00:00:57,417 We should consider them to be signed in." 26 00:00:58,740 --> 00:01:01,193 So the key here is that we're going to consider 27 00:01:01,193 --> 00:01:04,800 the existence of a token to mean 28 00:01:04,800 --> 00:01:06,630 that the user should be signed in. 29 00:01:06,630 --> 00:01:08,700 And when we say signed in, or you know 30 00:01:08,700 --> 00:01:09,570 when we say signed in 31 00:01:09,570 --> 00:01:11,730 what I really mean is we should show them 32 00:01:11,730 --> 00:01:13,170 like the sign out button here 33 00:01:13,170 --> 00:01:14,820 and they should also have access 34 00:01:14,820 --> 00:01:17,370 to the feature route as well. 35 00:01:17,370 --> 00:01:19,200 So when our application first boots up 36 00:01:19,200 --> 00:01:21,180 we need some way of checking to see 37 00:01:21,180 --> 00:01:22,356 whether or not the user is currently, 38 00:01:22,356 --> 00:01:25,080 currently has a token saved. 39 00:01:25,080 --> 00:01:26,580 And if they do, we need to make sure 40 00:01:26,580 --> 00:01:29,347 that we update our application state to say, 41 00:01:29,347 --> 00:01:31,617 "Yes this person is now authenticated." 42 00:01:32,970 --> 00:01:34,170 So let's give it a shot. 43 00:01:35,610 --> 00:01:38,430 The key is that we want to make this check 44 00:01:38,430 --> 00:01:40,110 and we want to kind of update our state 45 00:01:40,110 --> 00:01:42,720 before anything has been rendered to the DOM. 46 00:01:42,720 --> 00:01:45,429 Because by the time something has been rendered to the DOM 47 00:01:45,429 --> 00:01:48,720 we might have already tried rendering 48 00:01:48,720 --> 00:01:51,240 the require off or the feature route here, 49 00:01:51,240 --> 00:01:52,740 which would've already navigated 50 00:01:52,740 --> 00:01:55,500 the user back to the root route. 51 00:01:55,500 --> 00:01:57,540 So we can't just kind of stash something 52 00:01:57,540 --> 00:01:59,617 inside of a component will mount and assume, 53 00:01:59,617 --> 00:02:02,370 "Hey, like this is gonna take care of everything for us." 54 00:02:02,370 --> 00:02:03,840 Because by the time that something 55 00:02:03,840 --> 00:02:05,640 is about to be rendered to the DOM, 56 00:02:05,640 --> 00:02:09,270 it's probably already too late to log a user in 57 00:02:09,270 --> 00:02:12,450 in a way that's gonna have a really meaningful effect. 58 00:02:12,450 --> 00:02:13,779 So instead what we have to do 59 00:02:13,779 --> 00:02:17,520 is somehow update our application state 60 00:02:17,520 --> 00:02:21,300 before we start to render anything at all. 61 00:02:21,300 --> 00:02:23,580 In other words, we want to dispatch an action 62 00:02:23,580 --> 00:02:27,276 to our AUTH USER before we start to render anything. 63 00:02:27,276 --> 00:02:29,250 So to do this, we're gonna, you know, 64 00:02:29,250 --> 00:02:30,960 there's gonna be another instance where we put a little bit 65 00:02:30,960 --> 00:02:32,040 of code down the screen 66 00:02:32,040 --> 00:02:33,870 and then we talk about exactly what's going on. 67 00:02:33,870 --> 00:02:35,280 So let's put the code in first 68 00:02:35,280 --> 00:02:37,635 and then do a little bit of discussion. 69 00:02:37,635 --> 00:02:41,340 First thing I'm gonna do is inside of our provider tag 70 00:02:41,340 --> 00:02:43,230 I'm going to cut out 71 00:02:43,230 --> 00:02:45,300 the create store with middleware call. 72 00:02:45,300 --> 00:02:47,043 So I'm gonna cut out the entire thing. 73 00:02:47,043 --> 00:02:50,343 So the only thing I have now is provider with the store. 74 00:02:51,630 --> 00:02:54,360 Then right above the react DOM that render call 75 00:02:54,360 --> 00:02:56,129 I'm gonna make a new variable called store 76 00:02:56,129 --> 00:02:59,973 and I'm gonna paste the create store with middleware call. 77 00:03:01,830 --> 00:03:05,073 Now right below we're gonna add const token, 78 00:03:06,270 --> 00:03:11,270 local storage, get item, token. 79 00:03:11,370 --> 00:03:13,470 And so this is really the key here. 80 00:03:13,470 --> 00:03:18,470 If we have a token, consider the user to be signed in. 81 00:03:20,850 --> 00:03:22,743 So if token, 82 00:03:24,330 --> 00:03:27,630 we need to update application state. 83 00:03:27,630 --> 00:03:29,640 So this is it, this is the key right here. 84 00:03:29,640 --> 00:03:30,630 Basically what we're doing 85 00:03:30,630 --> 00:03:33,780 is we're creating an instance of our Redux store ahead time. 86 00:03:33,780 --> 00:03:36,060 And remember, the Redux store is what contains all 87 00:03:36,060 --> 00:03:38,820 of the state inside of our application. 88 00:03:38,820 --> 00:03:40,860 So if we create the store first 89 00:03:40,860 --> 00:03:42,540 then we can do this little check to see 90 00:03:42,540 --> 00:03:44,130 if we have our token. 91 00:03:44,130 --> 00:03:46,983 If they are, we need to update our application state. 92 00:03:48,480 --> 00:03:49,770 So all we have to do in here 93 00:03:49,770 --> 00:03:51,300 on this line right here is we need to figure 94 00:03:51,300 --> 00:03:55,710 out some way of up updating our application state. 95 00:03:55,710 --> 00:03:58,410 So I've, we've definitely gone over this many times. 96 00:03:58,410 --> 00:04:01,920 There is absolutely one way to update our application state. 97 00:04:01,920 --> 00:04:03,210 What is it? 98 00:04:03,210 --> 00:04:07,050 We dispatch an action or we call an action creator. 99 00:04:07,050 --> 00:04:08,700 So essentially what we need access 100 00:04:08,700 --> 00:04:11,460 to right here is the dispatch, dispatch method. 101 00:04:11,460 --> 00:04:16,110 The same one that we get from using Redux Thunk. 102 00:04:16,110 --> 00:04:17,880 So here's the really big surprise 103 00:04:17,880 --> 00:04:20,579 the big reveal at the end. 104 00:04:20,579 --> 00:04:22,800 That dispatch method that we've been using 105 00:04:22,800 --> 00:04:25,053 is a property of the store. 106 00:04:26,160 --> 00:04:29,460 So store.dispatch is our dispatch method. 107 00:04:29,460 --> 00:04:31,890 If we put any type of action in here, 108 00:04:31,890 --> 00:04:32,940 it's gonna be sent off 109 00:04:32,940 --> 00:04:36,000 to all the different reducers inside our application. 110 00:04:36,000 --> 00:04:38,820 And so that's really the big solution here 111 00:04:38,820 --> 00:04:41,250 for kind of updating our application 112 00:04:41,250 --> 00:04:42,993 before it's already been rendered. 113 00:04:44,370 --> 00:04:45,600 So here's the key. 114 00:04:45,600 --> 00:04:48,390 If we have a token, we're going to dispatch 115 00:04:48,390 --> 00:04:49,800 an action and we want 116 00:04:49,800 --> 00:04:54,117 that action specifically to be of type AUTH_USER. 117 00:04:55,140 --> 00:04:56,310 And if you recall the only thing 118 00:04:56,310 --> 00:04:59,370 that AUTH_USER does is change that signed in 119 00:04:59,370 --> 00:05:02,193 or that authenticated flag from true to false. 120 00:05:03,030 --> 00:05:05,160 One last piece of bookkeeping here. 121 00:05:05,160 --> 00:05:07,380 We have not imported this type here. 122 00:05:07,380 --> 00:05:09,810 So up on it by all of our import statements. 123 00:05:09,810 --> 00:05:12,750 I'm just going to import AUTH_USER 124 00:05:12,750 --> 00:05:17,750 from actions types like so. 125 00:05:19,380 --> 00:05:21,690 Then the very last thing we need to do is make sure 126 00:05:21,690 --> 00:05:23,460 that this store that now has 127 00:05:23,460 --> 00:05:26,880 this updated state actually gets passed to the provider. 128 00:05:26,880 --> 00:05:28,920 So down here at our provider call, 129 00:05:28,920 --> 00:05:32,283 we're gonna make sure we have store, store like so. 130 00:05:33,270 --> 00:05:34,470 So let's test this out in the browser 131 00:05:34,470 --> 00:05:37,500 and then do a quick review on what we just did. 132 00:05:37,500 --> 00:05:39,123 I'm gonna refresh the page. 133 00:05:40,140 --> 00:05:42,060 In this case, I've already got a token. 134 00:05:42,060 --> 00:05:44,700 And so you can notice that when I refresh the page 135 00:05:44,700 --> 00:05:46,800 I automatically see a sign out link 136 00:05:46,800 --> 00:05:49,440 instead of sign in and sign up. 137 00:05:49,440 --> 00:05:52,050 And I should also be able to make direct access 138 00:05:52,050 --> 00:05:53,615 to feature as well. 139 00:05:53,615 --> 00:05:56,820 And so again, I have access to feature here 140 00:05:56,820 --> 00:06:00,750 without having to go through the sign up or sign in process. 141 00:06:00,750 --> 00:06:03,700 So now the real test is if I sign out 142 00:06:05,220 --> 00:06:07,067 and then refresh 143 00:06:07,067 --> 00:06:09,900 I still see sign in and sign up. 144 00:06:09,900 --> 00:06:11,970 And I should also not have access 145 00:06:11,970 --> 00:06:14,730 to the feature route as well when I definitely don't. 146 00:06:14,730 --> 00:06:16,020 So awesome. 147 00:06:16,020 --> 00:06:18,000 So this definitely works out and it's all predicated 148 00:06:18,000 --> 00:06:20,910 on the idea that we're gonna pull out the token first 149 00:06:20,910 --> 00:06:22,410 and if we have a token 150 00:06:22,410 --> 00:06:26,040 we consider our user to still be authenticated. 151 00:06:26,040 --> 00:06:27,060 We did that update 152 00:06:27,060 --> 00:06:30,720 to application state by declaring our store beforehand. 153 00:06:30,720 --> 00:06:34,060 Remember, the store is what contains our Redux state 154 00:06:34,060 --> 00:06:37,020 and we are, we were able to automatically 155 00:06:37,020 --> 00:06:40,638 dispatch an action that signed our user in. 156 00:06:40,638 --> 00:06:42,750 Remember this action right here. 157 00:06:42,750 --> 00:06:45,600 We mapped up to the AUTH_USER. 158 00:06:45,600 --> 00:06:47,730 So here's our case AUTH_USER 159 00:06:47,730 --> 00:06:50,640 If they are, if we see this action come across 160 00:06:50,640 --> 00:06:53,447 then we consider our user to be authenticated. 161 00:06:53,447 --> 00:06:56,400 Cool. So this is definitely looking pretty darn good. 162 00:06:56,400 --> 00:06:58,641 One step closer to finishing up our application. 163 00:06:58,641 --> 00:07:01,200 I think there's one last big thing we need to do. 164 00:07:01,200 --> 00:07:05,520 We need to make sure that once we have our JWT token 165 00:07:05,520 --> 00:07:07,020 we are able to make requests 166 00:07:07,020 --> 00:07:09,480 to protected routes on our back end. 167 00:07:09,480 --> 00:07:11,830 So let's take care of that in the next section.