1 00:00:01,140 --> 00:00:02,580 ‫Let's now take a look 2 00:00:02,580 --> 00:00:06,060 ‫at how we can extend the functionality of Redux 3 00:00:06,060 --> 00:00:08,523 ‫by using something called Middleware. 4 00:00:10,800 --> 00:00:14,850 ‫So let's say that we wanted to make an asynchronous call 5 00:00:14,850 --> 00:00:16,890 ‫to some API. 6 00:00:16,890 --> 00:00:21,120 ‫So where could we actually do that in Redux? 7 00:00:21,120 --> 00:00:24,690 ‫Well, we can definitely not make the API call 8 00:00:24,690 --> 00:00:29,340 ‫inside a reducer because reducers need to be pure functions 9 00:00:29,340 --> 00:00:31,830 ‫with no side effects. 10 00:00:31,830 --> 00:00:35,730 ‫So by itself, a Redux store doesn't know anything 11 00:00:35,730 --> 00:00:39,540 ‫about performing asynchronous logic like this. 12 00:00:39,540 --> 00:00:43,650 ‫It only knows how to synchronously dispatch actions 13 00:00:43,650 --> 00:00:45,450 ‫and update the state. 14 00:00:45,450 --> 00:00:49,740 ‫Therefore, any asynchronous operations like that API call 15 00:00:49,740 --> 00:00:53,160 ‫need to happen outside a reducer. 16 00:00:53,160 --> 00:00:56,430 ‫So instead, should we maybe fetch the data 17 00:00:56,430 --> 00:01:00,060 ‫inside the component and then dispatch an action 18 00:01:00,060 --> 00:01:03,630 ‫to the store with that received data? 19 00:01:03,630 --> 00:01:06,360 ‫Well, that is actually possible, 20 00:01:06,360 --> 00:01:09,030 ‫but it's not an ideal solution 21 00:01:09,030 --> 00:01:12,060 ‫and the reason for that is that we usually want 22 00:01:12,060 --> 00:01:16,290 ‫to keep our components clean and free of data fetching 23 00:01:16,290 --> 00:01:19,590 ‫and we also want our important data fetching logic 24 00:01:19,590 --> 00:01:23,250 ‫encapsulated somewhere, so all in one place 25 00:01:23,250 --> 00:01:26,970 ‫and not have it spread all over the application. 26 00:01:26,970 --> 00:01:30,000 ‫Therefore, fetching data inside components, 27 00:01:30,000 --> 00:01:33,963 ‫like we have been doing all this time, is not ideal. 28 00:01:34,800 --> 00:01:39,000 ‫But if not in the store and not in the components, 29 00:01:39,000 --> 00:01:42,750 ‫then where do we perform asynchronous actions? 30 00:01:42,750 --> 00:01:47,040 ‫Well, that's where Middleware comes into action. 31 00:01:47,040 --> 00:01:50,760 ‫So in Redux, Middleware is basically a function 32 00:01:50,760 --> 00:01:54,960 ‫that sits between the dispatching and the store. 33 00:01:54,960 --> 00:01:58,350 ‫This means that a Middleware allows developers 34 00:01:58,350 --> 00:02:02,130 ‫to run some code after dispatching an action, 35 00:02:02,130 --> 00:02:06,600 ‫but before that action reaches the reducer in the store. 36 00:02:06,600 --> 00:02:10,080 ‫So again, usually after we dispatch, 37 00:02:10,080 --> 00:02:12,990 ‫the action immediately reaches the reducer 38 00:02:12,990 --> 00:02:15,300 ‫and the state is updated. 39 00:02:15,300 --> 00:02:19,320 ‫But with a Middleware, we can do something with the action 40 00:02:19,320 --> 00:02:23,700 ‫before that action actually gets into the reducer. 41 00:02:23,700 --> 00:02:26,790 ‫And therefore, this is the perfect place 42 00:02:26,790 --> 00:02:31,770 ‫for our asynchronous API call, as well as other operations, 43 00:02:31,770 --> 00:02:34,980 ‫such as setting timers, logging to the console, 44 00:02:34,980 --> 00:02:39,150 ‫or even pausing and canceling the action altogether. 45 00:02:39,150 --> 00:02:42,720 ‫So in essence, Middleware is the go-to place 46 00:02:42,720 --> 00:02:45,843 ‫for side effects in the Redux cycle. 47 00:02:46,770 --> 00:02:50,790 ‫Okay, so now that we know what Middleware is, 48 00:02:50,790 --> 00:02:54,120 ‫where does Middleware actually come from? 49 00:02:54,120 --> 00:02:57,510 ‫Well, we can write Middleware functions ourselves, 50 00:02:57,510 --> 00:03:01,410 ‫but usually, we just use some third party package. 51 00:03:01,410 --> 00:03:04,380 ‫And in the case of asynchronous operations, 52 00:03:04,380 --> 00:03:09,153 ‫the most popular Middleware in Redux is called Redux Thunk. 53 00:03:09,990 --> 00:03:14,460 ‫So let's see how Thunks work by analyzing what happens 54 00:03:14,460 --> 00:03:17,970 ‫to this action that we have seen before. 55 00:03:17,970 --> 00:03:21,900 ‫So now that we have this Thunk Middleware in place, 56 00:03:21,900 --> 00:03:25,590 ‫the action will no longer be immediately dispatched, 57 00:03:25,590 --> 00:03:28,470 ‫but will first get into the Middleware. 58 00:03:28,470 --> 00:03:31,560 ‫So into the Thunk, in this case. 59 00:03:31,560 --> 00:03:35,670 ‫Then we can start fetching some data inside the Thunk, 60 00:03:35,670 --> 00:03:39,750 ‫but it could also be some other asynchronous operation. 61 00:03:39,750 --> 00:03:42,063 ‫But let's stick to data fetching here. 62 00:03:43,020 --> 00:03:45,540 ‫Now, as soon as the data arrives, 63 00:03:45,540 --> 00:03:48,330 ‫we place it into the actions payload 64 00:03:48,330 --> 00:03:52,440 ‫and then we finally dispatch the action into the store, 65 00:03:52,440 --> 00:03:56,550 ‫where the state will then immediately get updated. 66 00:03:56,550 --> 00:04:00,600 ‫So basically, the Thunk allows Redux to wait 67 00:04:00,600 --> 00:04:04,290 ‫before dispatching the fetch data into the store. 68 00:04:04,290 --> 00:04:07,320 ‫Or in other words, we have used the Thunk 69 00:04:07,320 --> 00:04:11,010 ‫in order to defer dispatching into the future. 70 00:04:11,010 --> 00:04:12,870 ‫So to the point in which the data 71 00:04:12,870 --> 00:04:15,453 ‫that we need has actually arrived. 72 00:04:16,440 --> 00:04:19,950 ‫All right, but this is, of course, a lot easier 73 00:04:19,950 --> 00:04:23,280 ‫to understand in practice, and so let's implement this 74 00:04:23,280 --> 00:04:25,083 ‫in our application now.