1 00:00:00,864 --> 00:00:03,030 -: In the last section, we added some code 2 00:00:03,030 --> 00:00:04,710 to our Middleware to handle the case 3 00:00:04,710 --> 00:00:06,570 in which we didn't have a promise. 4 00:00:06,570 --> 00:00:09,360 I also just realized that I made a big typo here. 5 00:00:09,360 --> 00:00:11,220 I said, we don't have a promise. 6 00:00:11,220 --> 00:00:13,170 In fact, we would be reaching this area 7 00:00:13,170 --> 00:00:16,079 of our Middleware only if we did have a promise. 8 00:00:16,079 --> 00:00:17,700 So it would've been more appropriate to write, 9 00:00:17,700 --> 00:00:20,730 we have a promise here, just to be clear. 10 00:00:20,730 --> 00:00:23,550 So let's handle the case in which we do have a promise. 11 00:00:23,550 --> 00:00:26,640 If we have a promise, we wanna wait until it resolves. 12 00:00:26,640 --> 00:00:29,610 And then we wanna dispatch a new action 13 00:00:29,610 --> 00:00:32,340 with the successfully resolved promise. 14 00:00:32,340 --> 00:00:34,890 So this is gonna be one of those areas where 15 00:00:34,890 --> 00:00:36,450 it's just a little bit of a gotcha. 16 00:00:36,450 --> 00:00:39,390 It's just one line of code basically, 17 00:00:39,390 --> 00:00:41,880 and it's just something that's a, I dunno, very clever. 18 00:00:41,880 --> 00:00:44,280 Let's give it a shot and see what happens. 19 00:00:44,280 --> 00:00:46,980 So key number one, the first thing we wanna do is, 20 00:00:46,980 --> 00:00:51,270 make sure the action's promise resolves. 21 00:00:51,270 --> 00:00:53,010 Basically, we have to wait 22 00:00:53,010 --> 00:00:56,790 until that promise successfully fetches our list of users. 23 00:00:56,790 --> 00:00:58,200 That's step number one. 24 00:00:58,200 --> 00:01:01,230 So let's write some code that's going to basically tap 25 00:01:01,230 --> 00:01:03,270 into that situation. 26 00:01:03,270 --> 00:01:06,240 Action dot payload. So that's our promise. 27 00:01:06,240 --> 00:01:07,110 Dot then. 28 00:01:07,110 --> 00:01:10,080 So boom, that's it. The dot then. 29 00:01:10,080 --> 00:01:12,780 Any function that we pass to dot then 30 00:01:12,780 --> 00:01:17,357 is only gonna be called after the action has been resolved. 31 00:01:17,357 --> 00:01:19,050 And specifically any function that we pass here, 32 00:01:19,050 --> 00:01:21,693 is going to be resolved with the response, 33 00:01:22,591 --> 00:01:24,543 from the promise. 34 00:01:25,560 --> 00:01:28,620 So now we can add in a fat arrow function, 35 00:01:28,620 --> 00:01:30,123 for handling this case. 36 00:01:32,400 --> 00:01:35,100 Okay, so now, we've handled the case, 37 00:01:35,100 --> 00:01:36,450 or we've kind of handled this much. 38 00:01:36,450 --> 00:01:38,850 We're saying that yes, we're waiting until the promise 39 00:01:38,850 --> 00:01:42,270 resolves and we do have access to the response data. 40 00:01:42,270 --> 00:01:45,720 So now comes the step in our diagram here, where we say 41 00:01:45,720 --> 00:01:48,330 okay, we've got the, we've resolved, 42 00:01:48,330 --> 00:01:49,380 we've got the data. 43 00:01:49,380 --> 00:01:51,030 That's steps one and two right here. 44 00:01:51,030 --> 00:01:53,790 Now we just need to create a new action and send it 45 00:01:53,790 --> 00:01:56,730 through all of, all our Middlewares again. 46 00:01:56,730 --> 00:02:00,690 So, we need to create a new action, as step number one. 47 00:02:00,690 --> 00:02:04,113 To do this, let's uh, let's break it out to a, 48 00:02:05,970 --> 00:02:08,070 we'll just do this in one single line to start. 49 00:02:08,070 --> 00:02:09,930 And then maybe we'll, can expand it out 50 00:02:09,930 --> 00:02:11,130 to a full length function 51 00:02:11,130 --> 00:02:12,810 just to make sure everything's clear. 52 00:02:12,810 --> 00:02:14,073 Actually, you know what? 53 00:02:14,073 --> 00:02:16,140 Let's just do everything with a full, full size function 54 00:02:16,140 --> 00:02:18,540 rather than try to be fancy from the get go. 55 00:02:18,540 --> 00:02:22,140 So, that will use the long function keyword. 56 00:02:22,140 --> 00:02:24,940 This will be resolved with our response from the server. 57 00:02:26,490 --> 00:02:29,940 And then once we get here, we want to craft a new action. 58 00:02:29,940 --> 00:02:31,860 Okay? We want a, this is like our replacement. 59 00:02:31,860 --> 00:02:34,230 This is like the, hey, here's the copy of our action 60 00:02:34,230 --> 00:02:37,200 that has all the data that we actually care about. 61 00:02:37,200 --> 00:02:41,010 So inside this function, we'll say, take everything 62 00:02:41,010 --> 00:02:43,473 that the current action contains, 63 00:02:44,790 --> 00:02:48,183 but extend over it, our response. 64 00:02:49,620 --> 00:02:53,350 So take whatever data our action already contains 65 00:02:54,870 --> 00:02:58,530 and extend over it this new payload, which is the response. 66 00:02:58,530 --> 00:03:01,890 So, in the original action, we had a type and a payload. 67 00:03:01,890 --> 00:03:03,900 So, this line of code right here is making sure 68 00:03:03,900 --> 00:03:08,460 that we preserve the existing type onto our new action. 69 00:03:08,460 --> 00:03:10,860 And this second little bit here says, 70 00:03:10,860 --> 00:03:12,420 okay the old action, you know what? 71 00:03:12,420 --> 00:03:17,040 It's got that junk, that junk promise on it. 72 00:03:17,040 --> 00:03:18,450 We don't care about the promise anymore, 73 00:03:18,450 --> 00:03:20,100 all we care about is the data. 74 00:03:20,100 --> 00:03:22,380 So let's just knock off that entire promise. 75 00:03:22,380 --> 00:03:23,670 We don't, we don't need that promise anymore. 76 00:03:23,670 --> 00:03:26,520 Let's just knock it off and we will replace it 77 00:03:26,520 --> 00:03:28,260 with our response. 78 00:03:28,260 --> 00:03:29,670 So this line of code right here, 79 00:03:29,670 --> 00:03:33,750 is what creates our new action. 80 00:03:33,750 --> 00:03:35,460 Let's specifically label it as such. 81 00:03:35,460 --> 00:03:38,223 So I'll say const new action. 82 00:03:39,540 --> 00:03:43,953 And we'll say create a new action with the old type, 83 00:03:45,060 --> 00:03:50,060 but replace the promise with the response data. 84 00:03:52,950 --> 00:03:54,510 So let's go back to our diagram. 85 00:03:54,510 --> 00:03:57,150 We've now accomplished what I would probably refer 86 00:03:57,150 --> 00:03:58,860 to as step number three on here. 87 00:03:58,860 --> 00:04:01,650 We have created a new action 88 00:04:01,650 --> 00:04:05,400 with all the data except the, the, excuse me 89 00:04:05,400 --> 00:04:07,530 with all the data that was contained in the action 90 00:04:07,530 --> 00:04:10,380 except for we don't have the promise anymore. 91 00:04:10,380 --> 00:04:11,820 So now just one last step. 92 00:04:11,820 --> 00:04:15,030 We have to somehow send it through all the Middlewares again 93 00:04:15,030 --> 00:04:17,550 we have to go all the way back up to the top of the stack. 94 00:04:17,550 --> 00:04:20,190 And let's say we've got five other Middlewares in here. 95 00:04:20,190 --> 00:04:21,810 We wanna make sure that the action flows 96 00:04:21,810 --> 00:04:24,210 through all those different Middlewares. 97 00:04:24,210 --> 00:04:25,620 So, to make that happen, 98 00:04:25,620 --> 00:04:28,050 we don't wanna call next with the action. 99 00:04:28,050 --> 00:04:30,480 Next just forwards it, forwards our action 100 00:04:30,480 --> 00:04:32,430 onto the next Middleware. 101 00:04:32,430 --> 00:04:33,263 And we don't want that. 102 00:04:33,263 --> 00:04:35,790 We wanna make sure that our action goes through all 103 00:04:35,790 --> 00:04:36,623 of the Middlewares again. 104 00:04:36,623 --> 00:04:39,630 And I'll talk about exactly why in just a second. 105 00:04:39,630 --> 00:04:41,670 So to make sure that our action flows through all 106 00:04:41,670 --> 00:04:43,470 of our Middleware. 107 00:04:43,470 --> 00:04:46,800 We use the dispatch method up here at the top, so again, 108 00:04:46,800 --> 00:04:50,400 this dispatch is a function. Let's go ahead and add it in. 109 00:04:50,400 --> 00:04:53,793 We'll say just dispatch new action. 110 00:04:54,870 --> 00:04:57,900 Dispatch literally means take this action, 111 00:04:57,900 --> 00:05:00,810 and send it through a very topmost reducer again. 112 00:05:00,810 --> 00:05:02,790 Just pretend like it's a brand new action, 113 00:05:02,790 --> 00:05:04,230 send it through everything again. 114 00:05:04,230 --> 00:05:05,670 That's the purpose of dispatch, 115 00:05:05,670 --> 00:05:08,250 and that's how it differs from next. 116 00:05:08,250 --> 00:05:10,170 Next just goes to the next Middleware, 117 00:05:10,170 --> 00:05:12,930 dispatch means run the entire cycle over again. 118 00:05:12,930 --> 00:05:15,690 Go up to the very top and run this action, 119 00:05:15,690 --> 00:05:17,370 through everything again. 120 00:05:17,370 --> 00:05:19,650 Now there's two follow up points here I wanna make. 121 00:05:19,650 --> 00:05:22,980 First, your question might be, okay, well Steven 122 00:05:22,980 --> 00:05:25,050 I understand like we're gonna dispatch this action 123 00:05:25,050 --> 00:05:26,040 from the very top again. 124 00:05:26,040 --> 00:05:30,060 But when we hit this Middleware again, cause we are, 125 00:05:30,060 --> 00:05:32,580 when we hit this Middleware again, aren't we just going to 126 00:05:32,580 --> 00:05:35,910 like try to chain on to the promise again, right? 127 00:05:35,910 --> 00:05:38,250 Aren't we just gonna be in this infinite loop? 128 00:05:38,250 --> 00:05:40,530 So, my response to that is that, no 129 00:05:40,530 --> 00:05:42,420 not on the next time through. 130 00:05:42,420 --> 00:05:44,010 The next time through our payload, 131 00:05:44,010 --> 00:05:45,780 is not gonna be a promise anymore. 132 00:05:45,780 --> 00:05:48,033 It's gonna be our response object 133 00:05:48,033 --> 00:05:49,200 our data from the back end. 134 00:05:49,200 --> 00:05:51,330 And so we're gonna catch on this early return 135 00:05:51,330 --> 00:05:54,270 case where we just go onto the next Middleware. 136 00:05:54,270 --> 00:05:58,170 So anytime we return a promise in an action, 137 00:05:58,170 --> 00:06:01,200 and it hits this Middleware, it's gonna hit it one time 138 00:06:01,200 --> 00:06:04,350 hit the dispatch, go all the way to the top again 139 00:06:04,350 --> 00:06:07,140 and then come in again. But that second time, 140 00:06:07,140 --> 00:06:09,153 it'll hit the early return case. 141 00:06:10,020 --> 00:06:12,780 So, that's a question that you might have, number one. 142 00:06:12,780 --> 00:06:14,970 Question you might have, number two is, 143 00:06:14,970 --> 00:06:16,560 why are we using dispatch here? 144 00:06:16,560 --> 00:06:18,930 Why aren't we just using the next queue? 145 00:06:18,930 --> 00:06:20,640 Why don't we just pass it on to the, you know, 146 00:06:20,640 --> 00:06:22,530 next Middleware we have in the chain. 147 00:06:22,530 --> 00:06:25,110 And so this is something that's actually really important 148 00:06:25,110 --> 00:06:26,970 especially when you're writing custom Middleware 149 00:06:26,970 --> 00:06:28,800 for your own applications. 150 00:06:28,800 --> 00:06:30,930 Let's go back to this earlier diagram again 151 00:06:30,930 --> 00:06:33,360 where we had several Middleware, in a chain, 152 00:06:33,360 --> 00:06:35,433 several Middleware, Middleware in a row. 153 00:06:37,050 --> 00:06:40,230 Let's say that the Middleware that we just wrote, 154 00:06:40,230 --> 00:06:42,510 you know our async one is number three. 155 00:06:42,510 --> 00:06:45,150 Let's say we're the last one on the chain. 156 00:06:45,150 --> 00:06:48,180 But let's also say that maybe Middleware number one, 157 00:06:48,180 --> 00:06:51,990 wants to be responsible for logging every single action 158 00:06:51,990 --> 00:06:54,360 that comes through before they hit the reducers. 159 00:06:54,360 --> 00:06:57,360 Or maybe there's some other action or some operation 160 00:06:57,360 --> 00:06:59,820 that we have on this other Middleware that must always 161 00:06:59,820 --> 00:07:01,080 happen a hundred percent of the time 162 00:07:01,080 --> 00:07:04,680 with every action before it hits the reducers. 163 00:07:04,680 --> 00:07:07,440 If we got into our Middleware, number three 164 00:07:07,440 --> 00:07:09,330 and we said, okay, just forward on to the next one. 165 00:07:09,330 --> 00:07:11,280 Like, here's the response we're done. 166 00:07:11,280 --> 00:07:13,320 It would skip number one Middleware, 167 00:07:13,320 --> 00:07:15,450 it would skip that first one. 168 00:07:15,450 --> 00:07:17,820 Now we can reorder our Middleware, 169 00:07:17,820 --> 00:07:19,110 but the goal here is to make sure 170 00:07:19,110 --> 00:07:21,330 that we always write our Middleware in such a manner 171 00:07:21,330 --> 00:07:24,990 that it doesn't matter what order they execute in. 172 00:07:24,990 --> 00:07:27,870 That's the key. We never want to make an assumption about, 173 00:07:27,870 --> 00:07:30,510 oh my action is first gonna hit this very particular 174 00:07:30,510 --> 00:07:33,540 Middleware, and then it's going to definitely always next 175 00:07:33,540 --> 00:07:35,640 hit this other one right after it. 176 00:07:35,640 --> 00:07:36,870 So again, the goal is to make sure 177 00:07:36,870 --> 00:07:39,840 that we write Middleware that is completely oblivious 178 00:07:39,840 --> 00:07:41,760 as to what order it's being ran in. 179 00:07:41,760 --> 00:07:44,460 And so that's why whenever we make a modification 180 00:07:44,460 --> 00:07:48,510 to an action or we change it in some very fundamental way 181 00:07:48,510 --> 00:07:50,670 we always dispatch the action again. 182 00:07:50,670 --> 00:07:53,160 So, it goes up to the top and flows in again, 183 00:07:53,160 --> 00:07:56,223 as opposed to just going to the next Middleware. 184 00:07:57,090 --> 00:07:58,440 Okay, so this looks great right here, 185 00:07:58,440 --> 00:08:00,150 but I've also been talking for a long time 186 00:08:00,150 --> 00:08:02,040 so I'm gonna save this and let's go ahead 187 00:08:02,040 --> 00:08:04,443 and give it a test inside of the next section.