1 00:00:00,850 --> 00:00:06,440 In the last video we spoke about why this async await syntax is throwing off our action creator. 2 00:00:06,510 --> 00:00:11,280 Now whenever I tell someone that OIA async wait right here throwing it off and it's making our requests 3 00:00:11,290 --> 00:00:12,510 not work as expected. 4 00:00:12,540 --> 00:00:16,250 I always get a very common question as a follow up immediately afterwards. 5 00:00:16,500 --> 00:00:22,980 People very frequently say okay well what if we just remove a async away like so and so now we don't 6 00:00:22,980 --> 00:00:25,450 get any special syntax when this gets transported to. 7 00:00:25,470 --> 00:00:26,470 Yes Phife. 8 00:00:26,550 --> 00:00:31,250 Now we are in fact going to be returning a plain javascript object. 9 00:00:31,450 --> 00:00:34,420 We would not really refer to this variable as a response anymore. 10 00:00:34,420 --> 00:00:37,500 It is technically a promise. 11 00:00:37,550 --> 00:00:39,500 So I'm going to assign Promus like so. 12 00:00:39,500 --> 00:00:44,030 Now the reason we refer to this as a promise is that when we call this line of code right here we are 13 00:00:44,030 --> 00:00:49,850 making requests over to our API that is going to take some amount of time to complete that request like 14 00:00:49,850 --> 00:00:55,890 it might take 100 milliseconds or 500 milliseconds or 10 seconds who knows how long it's going to take. 15 00:00:56,030 --> 00:00:57,980 So we make this request right here. 16 00:00:58,100 --> 00:01:02,270 And then what gets returned to us and assigned to this variable is something that we call a promise 17 00:01:02,300 --> 00:01:07,880 and that promise object essentially is going to give us a little finger or a handle a little notification 18 00:01:08,060 --> 00:01:11,390 when the request is completed at some point in the future. 19 00:01:11,390 --> 00:01:15,650 So without the syncopate syntax we do not get some data back right here. 20 00:01:15,650 --> 00:01:21,350 Instead we get a promise object that is going to give us access to our data when we eventually get it 21 00:01:21,380 --> 00:01:23,900 at some point in the future. 22 00:01:23,900 --> 00:01:28,120 Now with that in mind the code you see here still works just fine. 23 00:01:28,340 --> 00:01:33,120 We can save this flip back over to the browser and you'll see that the error message has gone away. 24 00:01:33,200 --> 00:01:36,690 It's because we no longer have the nasty async await syntax. 25 00:01:36,740 --> 00:01:39,620 We are returning a normal javascript object. 26 00:01:39,620 --> 00:01:44,270 So even though the error message went away this code that you see right here is still probably not going 27 00:01:44,270 --> 00:01:45,970 to work as you expect. 28 00:01:46,130 --> 00:01:48,850 So in this video I want to tell you why this would not work. 29 00:01:48,860 --> 00:01:55,520 As you might expect OK so as you might guess the code snippet that we see is essentially tied to this 30 00:01:55,520 --> 00:01:56,080 item right here. 31 00:01:56,080 --> 00:02:01,530 The second reason that fenceposts is not going to work by the time our action object gets to reduce 32 00:02:01,530 --> 00:02:06,680 or we will not have retrieved our data from that API that is the root or the crux of the issue. 33 00:02:06,690 --> 00:02:11,490 That is why this alternate syntax right here is not going to work out as you might expect. 34 00:02:11,490 --> 00:02:15,010 So let me show you a couple of diagrams to help you understand exactly why. 35 00:02:15,020 --> 00:02:16,190 So here's our redux cycle. 36 00:02:16,190 --> 00:02:20,230 We've looked at this diagram a couple of times at the very top. 37 00:02:20,270 --> 00:02:21,480 We've got our action creator. 38 00:02:21,500 --> 00:02:23,990 We call the action creator returns in action. 39 00:02:24,110 --> 00:02:29,450 That action is going to get dispatch automatically by the re-act redux library sent off to all of our 40 00:02:29,450 --> 00:02:34,580 different reducers the reducers are going to rerun and we get some new state object back. 41 00:02:34,580 --> 00:02:40,870 Now here's something very important to keep in mind when we call an action Creator and it returns the 42 00:02:40,870 --> 00:02:43,700 action and we dispatch it and it goes to our reducers. 43 00:02:43,900 --> 00:02:50,580 All of those steps right there are going to be executed in a fraction of a fraction of a second. 44 00:02:50,590 --> 00:02:53,220 We're talking about like fractions of a millisecond here. 45 00:02:53,230 --> 00:02:56,110 Amazingly amazingly quickly. 46 00:02:56,200 --> 00:03:01,690 So the time that it takes to color action creator return the action and get that overtalk reducers is 47 00:03:01,960 --> 00:03:04,040 as fast as you can possibly imagine. 48 00:03:04,090 --> 00:03:10,130 Instantaneous now that causes an issue with the fact that we are making an asynchronous requests here. 49 00:03:10,610 --> 00:03:12,630 Here's what is really going on behind the scenes. 50 00:03:12,640 --> 00:03:17,470 So I've got two separate flows here on the left hand side is what is happening inside of redux on the 51 00:03:17,470 --> 00:03:22,510 right hand side is what is happening with our request so we color action creator. 52 00:03:22,510 --> 00:03:24,270 We return that action object again. 53 00:03:24,300 --> 00:03:27,940 You know we're talking about this refactored code right here where we've got the promise on the palette 54 00:03:27,940 --> 00:03:31,570 property we dispatched that action. 55 00:03:31,580 --> 00:03:35,170 So the action gets sent to all of our reducers producers run. 56 00:03:35,180 --> 00:03:38,870 We don't currently really have any functional reducers but I'm sure you can imagine that we're going 57 00:03:38,870 --> 00:03:44,540 to want to reach into the response and pull out the list of posts that we fetch but in this case we 58 00:03:44,540 --> 00:03:47,270 do not yet have any data return from that API. 59 00:03:47,270 --> 00:03:49,550 Remember these series of steps right here. 60 00:03:49,550 --> 00:03:53,760 Instantaneous as fast as you can possibly imagine. 61 00:03:53,850 --> 00:03:57,950 Now at the same time that we call the action creator we are going to make the request over to the type 62 00:03:57,950 --> 00:04:03,020 of code API that request is going to take some unknown amount of time. 63 00:04:03,030 --> 00:04:05,170 It might take 10 milliseconds. 64 00:04:05,190 --> 00:04:10,800 It might take ten thousand milliseconds it might take 10 minutes who knows its going to take some crazy 65 00:04:10,800 --> 00:04:13,800 amount of time to eventually get a response back from that API. 66 00:04:14,130 --> 00:04:20,040 So by the time we finally get a response from the API our action has long since been processed by our 67 00:04:20,040 --> 00:04:22,410 reducers our reducers have already ran. 68 00:04:22,650 --> 00:04:28,080 And they have looked inside that promise object and said oh the request isnt complete and theres nothing 69 00:04:28,080 --> 00:04:32,030 that we can do inside of our reducers to somehow delay them from running. 70 00:04:32,040 --> 00:04:35,970 There's nothing we can do over here that says hey reduce or like just hold on for a second wait for 71 00:04:35,970 --> 00:04:38,860 this promise to get some data back and then run yourself. 72 00:04:38,940 --> 00:04:40,670 Thats not an option here. 73 00:04:40,710 --> 00:04:46,260 So I think you get the idea now with this alternate syntax when we return an object it gets sent off 74 00:04:46,260 --> 00:04:52,900 to the reducers but that all happened so quickly that it happens and completes itself way before we 75 00:04:52,900 --> 00:04:55,370 ever get any data back from our API. 76 00:04:55,570 --> 00:05:00,700 So in other words even if we use this alternate syntax right here without the async or awaits we would 77 00:05:00,700 --> 00:05:05,070 still run into an issue where we could not get access to our data. 78 00:05:05,100 --> 00:05:06,110 All right. 79 00:05:06,360 --> 00:05:08,040 So thats pretty much it. 80 00:05:08,100 --> 00:05:12,960 That is the two reasons that are fecche post action creator was not working as intended. 81 00:05:12,960 --> 00:05:18,270 The first one was pretty obvious only in the fact that I should say pretty obvious I mean to say obvious 82 00:05:18,270 --> 00:05:21,450 in the fact that we got that big nasty error message that it was. 83 00:05:21,540 --> 00:05:25,620 Thats what I meant by that I mean to say we saw an error message that made it very clear that something 84 00:05:25,620 --> 00:05:26,350 was going wrong. 85 00:05:26,610 --> 00:05:31,260 But the second problem was much more subtle and really requires you to understand what is going on behind 86 00:05:31,260 --> 00:05:33,120 the scenes with redux. 87 00:05:33,120 --> 00:05:37,260 So now that we understand these big problems are going to take a quick pause right here when we come 88 00:05:37,260 --> 00:05:41,520 back the next section we're going to start to discuss how we're going to make use of this middleware 89 00:05:41,520 --> 00:05:44,960 thing called it redux thunk and how it's going to solve all these issues. 90 00:05:45,000 --> 00:05:46,660 So quick pause and I'll see you in just a minute.