1 00:00:00,660 --> 00:00:05,810 Now were successfully dispatching action every single time we make a request off to this end point. 2 00:00:05,940 --> 00:00:10,950 We need to make sure that this action right here gets picked up inside of our cloth reducer. 3 00:00:10,950 --> 00:00:15,540 Now before we flip over to the author douceur and start working on that I want to remind you that this 4 00:00:15,630 --> 00:00:19,750 rez object right here is the output from X-posts. 5 00:00:19,770 --> 00:00:23,940 It represents the underline request that was made to the back end server. 6 00:00:24,240 --> 00:00:29,580 Now if we look at the console log of that response that we still have in cyber consul over here. 7 00:00:29,730 --> 00:00:35,640 So here's the payload in here all the different properties that are tied to that response object. 8 00:00:35,640 --> 00:00:40,080 Now you look at this thing and we've got some config we've got headers we've got requests status blah 9 00:00:40,080 --> 00:00:46,320 blah blah but at the end of the day the only real piece of data that we care about here at all is really 10 00:00:46,320 --> 00:00:52,470 this data property just this data property nothing else on this response object. 11 00:00:52,470 --> 00:00:58,580 So back inside of our action creator rather than returning an object that passes along the entire response. 12 00:00:58,710 --> 00:01:03,700 I think that we should pass back as a payload just the rez dot data property. 13 00:01:03,810 --> 00:01:10,620 So just rez dot data just the user model because that's really the only thing that our application and 14 00:01:10,620 --> 00:01:13,170 especially our producer cares about at all. 15 00:01:13,170 --> 00:01:17,330 Nothing else really cares about the headers or requests or anything like that. 16 00:01:17,340 --> 00:01:22,380 So back inside of our action creator I mean to say that when we dispatch this action we're going to 17 00:01:22,380 --> 00:01:23,090 pass along. 18 00:01:23,100 --> 00:01:26,300 RAZ dot data like so. 19 00:01:26,610 --> 00:01:29,870 So just the response data property. 20 00:01:30,210 --> 00:01:34,890 OK so now we can flip over to our reducers author reducer G-S file. 21 00:01:34,920 --> 00:01:37,110 So here is where we put together some boilerplate. 22 00:01:37,110 --> 00:01:41,250 Earlier on inside the course just to kind of get this reducers put together. 23 00:01:41,280 --> 00:01:47,190 We're now going to import the fetch user action type and then set up an additional case on our switch 24 00:01:47,190 --> 00:01:50,720 statement to watch for that action to come into this reducer. 25 00:01:51,030 --> 00:01:59,820 So at the top of the file we will import our action type which is Fettes user from up one directory 26 00:01:59,910 --> 00:02:00,940 into actions. 27 00:02:00,940 --> 00:02:07,070 Type start ups so up into actions slash types. 28 00:02:07,200 --> 00:02:10,300 Now we can add on a case statement inside of the switch statement. 29 00:02:10,380 --> 00:02:12,860 So here's a case that user. 30 00:02:13,020 --> 00:02:18,530 So if we see an action with type fetch user then we want to do this thing right here. 31 00:02:18,630 --> 00:02:23,400 Now before we start to return the actions payload or anything like that I want to think very carefully 32 00:02:23,430 --> 00:02:28,460 about the life cycle of this reducer and some of the different values that it's going to produce. 33 00:02:28,470 --> 00:02:29,920 And let me tell you why. 34 00:02:30,570 --> 00:02:32,350 Let's go back to our mockup really quick. 35 00:02:32,360 --> 00:02:35,940 It's the mockup that includes the header right here. 36 00:02:35,940 --> 00:02:41,310 So when we look at this header remember the content on the right hand side is going to change depending 37 00:02:41,310 --> 00:02:43,620 on whether or not the user is logged in. 38 00:02:43,620 --> 00:02:49,320 Now let me send out or let me like provide you a sequence sequence of events that might make the header 39 00:02:49,320 --> 00:02:51,930 behave slightly unexpectedly. 40 00:02:51,930 --> 00:02:57,510 I want you to imagine for a second that when our application first boots up and we make an Ajax request 41 00:02:57,510 --> 00:02:58,720 to our back end server. 42 00:02:58,770 --> 00:03:02,450 So essentially a thing that decides whether or not we are currently logged in. 43 00:03:02,790 --> 00:03:06,520 What would happen if that request took a very long time to complete. 44 00:03:06,540 --> 00:03:12,510 So maybe our user is on a 3G network connection or just some kind of connection that is very slow and 45 00:03:12,510 --> 00:03:17,160 it might take some amount of time for this request to actually complete and get back to the current 46 00:03:17,160 --> 00:03:18,020 user. 47 00:03:18,420 --> 00:03:22,670 If that were to happen we might temporarily see some content inside the header. 48 00:03:22,680 --> 00:03:24,960 That would be like not quite what we expect. 49 00:03:24,960 --> 00:03:30,870 For example if we say that by default show the logging with Google button and then that long running 50 00:03:30,880 --> 00:03:34,910 request eventually finishes and we find out that we in fact are logged in. 51 00:03:35,100 --> 00:03:39,930 All of a sudden the content up in the header would change over to the content that we would expect to 52 00:03:39,930 --> 00:03:42,590 see when the user is actually logged in. 53 00:03:42,660 --> 00:03:48,270 So we don't want to fall into this very easy trap to fall into where we kind of assume that the user 54 00:03:48,330 --> 00:03:55,850 is or is not logged in and then show the UI according to that flag because it just means that as soon 55 00:03:55,870 --> 00:04:00,480 as it takes a long time to decide whether or not the user is logged in the user is going to see one 56 00:04:00,480 --> 00:04:04,130 state of the UI and then suddenly see it change over to the other state. 57 00:04:04,200 --> 00:04:07,890 Once we find out that they are in fact logged in. 58 00:04:07,890 --> 00:04:13,020 So with that in mind we need to be kind of very careful here when we think about the different return 59 00:04:13,020 --> 00:04:14,960 values from this reducer. 60 00:04:15,210 --> 00:04:18,590 So let me give you a summary of how we're going to tackle this. 61 00:04:18,600 --> 00:04:20,110 Here's what we're going to do. 62 00:04:20,850 --> 00:04:21,130 OK. 63 00:04:21,150 --> 00:04:25,110 So we really have three different situations of our application. 64 00:04:25,110 --> 00:04:27,130 Three different cases. 65 00:04:27,240 --> 00:04:32,430 Case number one is the case in which we make a request to our back end to get the current user and the 66 00:04:32,430 --> 00:04:35,100 request does not instantly resolve. 67 00:04:35,100 --> 00:04:39,510 So essentially we make the request to find out if the user is logged in and then we kind of sit there 68 00:04:39,780 --> 00:04:44,520 and we're just twiddling your thumbs waiting to hear back to see whether or not the users actually logged 69 00:04:44,520 --> 00:04:45,310 in. 70 00:04:45,330 --> 00:04:50,160 Now I'm going to suggest that while that is the case while we are waiting for that request to finish 71 00:04:50,520 --> 00:04:52,590 our producer should return. 72 00:04:53,220 --> 00:04:58,500 We're going to say that inside of our application our return value of no means we don't really know 73 00:04:58,530 --> 00:05:00,360 if the user is logged in right now. 74 00:05:00,360 --> 00:05:02,960 We don't know if they are or we don't know if they're not. 75 00:05:02,970 --> 00:05:05,580 So we're going to say no we don't know. 76 00:05:05,580 --> 00:05:06,890 We're still making a request. 77 00:05:06,900 --> 00:05:08,190 The request is still pending. 78 00:05:08,190 --> 00:05:11,690 We're waiting to find out if the user is logged in. 79 00:05:11,730 --> 00:05:13,520 Then if the user is logged in. 80 00:05:13,530 --> 00:05:19,530 So at this point in time we can say that the request is complete diot the author Duzer can return the 81 00:05:19,530 --> 00:05:21,050 entire user model. 82 00:05:21,360 --> 00:05:26,160 But if the user is not logged in so the request is complete and it turns out they are not logged in 83 00:05:26,460 --> 00:05:29,520 then we should instead just return the value false. 84 00:05:29,520 --> 00:05:36,150 So this gives us three distinct values coming out of our reducer that we can use to decide the exact 85 00:05:36,150 --> 00:05:38,390 state of the authentication flow. 86 00:05:38,520 --> 00:05:44,430 Either the user is logged in they're not logged in or we are still waiting to find out if they are or 87 00:05:44,430 --> 00:05:50,840 aren't so let's make sure that our author douceur conforms to these different cases right here. 88 00:05:51,060 --> 00:05:57,120 The first one that will take care of is the base case which is to return NULL while our request is still 89 00:05:57,120 --> 00:05:57,550 pending. 90 00:05:57,570 --> 00:06:02,970 While we are still trying to figure out whether or not the user is logged in so handling that case is 91 00:06:03,030 --> 00:06:08,760 actually pretty straightforward inside of our douceur we are currently defaulting our stock value to 92 00:06:08,760 --> 00:06:12,780 be an empty object rather than always returning an empty object. 93 00:06:12,780 --> 00:06:15,130 We could instead return. 94 00:06:15,420 --> 00:06:16,360 No. 95 00:06:16,860 --> 00:06:21,870 So if we are turning like this that means OK first time there are douceur runs on our application first 96 00:06:21,870 --> 00:06:22,710 boot up. 97 00:06:22,740 --> 00:06:29,010 We are going to immediately return all which indicates that by default we have no clue as to whether 98 00:06:29,010 --> 00:06:31,790 or not the user is actually logged in. 99 00:06:31,950 --> 00:06:37,680 Then when we actually hear back from our request only at this point in time when we actually hear from 100 00:06:37,680 --> 00:06:44,810 that Fettes user action will we return a new value that will be either the user model or false. 101 00:06:44,940 --> 00:06:52,680 So we will say that we will return action payload and remember action payload is the user model. 102 00:06:52,680 --> 00:06:56,790 Now there's one more little gotcha kind of tucked away in this line right here. 103 00:06:57,270 --> 00:06:59,250 When we see our console log right now. 104 00:06:59,490 --> 00:07:02,430 So here's the console log for the action that comes into the producer. 105 00:07:02,460 --> 00:07:07,710 We have verified a couple of times now and I've got to pull the app back up. 106 00:07:07,710 --> 00:07:08,460 Here we go. 107 00:07:08,460 --> 00:07:14,870 So when the user is logged in action not payload is now the actual user model. 108 00:07:14,880 --> 00:07:19,080 However this doesn't really accommodate for the case that the user is not logged in. 109 00:07:19,080 --> 00:07:22,710 So really quick let me log out and I want to show you something kind of awkward. 110 00:07:23,010 --> 00:07:30,390 So over in the new tab I'm going to go to localhost 5000 slash API slash log out remerge. 111 00:07:30,420 --> 00:07:31,920 That's how we log out. 112 00:07:31,920 --> 00:07:33,960 So I'm now logged out of the application. 113 00:07:33,960 --> 00:07:37,830 If I go back over to the re-act side and refresh the page. 114 00:07:37,830 --> 00:07:44,190 Now when we see that action has a payload of empty string because when the user is not logged in the 115 00:07:44,190 --> 00:07:49,710 API is just returning an empty string which means essentially no you're not logged in. 116 00:07:49,890 --> 00:07:52,060 So we don't really want to return empty string here. 117 00:07:52,080 --> 00:07:53,220 That's kind of confusing. 118 00:07:53,220 --> 00:07:58,620 So rather than returning empty string we're going to make sure that we explicitly return the value false 119 00:07:59,190 --> 00:08:03,160 to do so inside every turn statement right here. 120 00:08:03,180 --> 00:08:05,110 We will say action payload. 121 00:08:05,210 --> 00:08:09,080 This is going to be either an object or an empty string. 122 00:08:09,210 --> 00:08:12,900 To make sure that that empty string will actually end up as false. 123 00:08:12,900 --> 00:08:17,820 We're going to use a little bit of trickery with javascript so let's add in the code and we'll talk 124 00:08:17,820 --> 00:08:18,950 about what it's doing. 125 00:08:18,960 --> 00:08:25,260 So when I say action payload or false like so. 126 00:08:25,260 --> 00:08:30,030 So this might be kind of new to you but let's flip over to the terminal really quick and see what it 127 00:08:30,030 --> 00:08:31,500 actually does. 128 00:08:31,950 --> 00:08:36,960 So I know that whenever you're making use of javascript an empty string like this is interpreted to 129 00:08:36,960 --> 00:08:39,180 be a falsie value. 130 00:08:39,180 --> 00:08:46,260 So if I put an exclamation in front of that to kind of reverse the boolean value here it gets turned 131 00:08:46,260 --> 00:08:47,210 into true. 132 00:08:47,480 --> 00:08:52,740 And so I could just as easily do flip the reverse of true and now it really gets what it truly is. 133 00:08:52,740 --> 00:08:53,950 False. 134 00:08:54,060 --> 00:09:02,340 So this statement right here essentially says if that is an empty string or false will return the value 135 00:09:02,340 --> 00:09:03,150 false. 136 00:09:03,180 --> 00:09:04,970 So see how we get false right here. 137 00:09:06,050 --> 00:09:10,910 We're going to use this little trick right here in which the first element inside the boolean expression 138 00:09:10,910 --> 00:09:15,070 is treated as falsie which causes the entire boolean statement to return false. 139 00:09:15,070 --> 00:09:17,020 We're going to use it several times throughout the course. 140 00:09:17,060 --> 00:09:21,370 So this is just one of the first times that we're kind of getting our eyes on it. 141 00:09:21,410 --> 00:09:21,750 OK. 142 00:09:21,800 --> 00:09:28,760 So now we have made sure that the author reducer will always either return. 143 00:09:29,650 --> 00:09:32,810 The user model or the value false. 144 00:09:33,080 --> 00:09:35,060 So let's now test this out inside the browser. 145 00:09:35,140 --> 00:09:38,650 I'll flip back over all refresh. 146 00:09:38,810 --> 00:09:40,960 I did not save this file I think. 147 00:09:41,090 --> 00:09:46,050 Make sure make sure I save it oh my mistake. 148 00:09:46,050 --> 00:09:49,470 So we are counsel lugging the payload right here which is always going to be empty string. 149 00:09:49,470 --> 00:09:52,350 We are not actually cancel logging the value of the reducer. 150 00:09:52,350 --> 00:09:53,130 My mistake. 151 00:09:53,370 --> 00:09:58,590 So at this point we can really safely assume that the reducer is behaving the way we expect and our 152 00:09:58,590 --> 00:10:03,160 user or I should say our off piece of state is always going to be either. 153 00:10:03,630 --> 00:10:06,670 The action or the user model or false. 154 00:10:06,780 --> 00:10:09,510 So we don't really have a good way to fully test that just yet. 155 00:10:09,540 --> 00:10:14,190 So let's continue with the next section we're going to make sure that the header is aware of the current 156 00:10:14,190 --> 00:10:20,100 authentication state and at that point we can do a little bit more verification and be 100 percent sure 157 00:10:20,100 --> 00:10:22,670 that the author douceur is doing the right thing. 158 00:10:22,680 --> 00:10:26,460 Now the last thing I want to do inside of here is make sure that we clean up the console log statement 159 00:10:26,730 --> 00:10:28,120 so we can take that out. 160 00:10:28,620 --> 00:10:28,930 OK. 161 00:10:28,930 --> 00:10:29,760 So it looks good. 162 00:10:29,880 --> 00:10:34,320 Let's continue with the next section and continue working on the content that is displayed inside the 163 00:10:34,320 --> 00:10:34,810 letter. 164 00:10:34,890 --> 00:10:36,370 So I'll see you in just a second.