WEBVTT 00:00.000 --> 00:05.220 Okay, before we get our hands dirty with RTK Query Redux Toolkit query, let's have a quick discussion 00:05.220 --> 00:10.830 about what this is and what benefits it gives us and why we should use it in our application. 00:10.860 --> 00:14.640 This is actually quite a major update to this training course from the original version. 00:14.640 --> 00:16.890 When I originally wrote the code for this course. 00:17.130 --> 00:21.600 RTK query wasn't yet available with the Redux toolkit. 00:21.600 --> 00:28.080 It was added either just about or just after I released the original version of this training course. 00:28.350 --> 00:33.810 And it's worth the update because this is worth using, especially when using Redux, because it's all 00:33.810 --> 00:35.910 integrated into our store. 00:35.910 --> 00:41.820 So when we do go and fetch data with this tool, then it uses Redux as a kind of backing store for what 00:41.820 --> 00:44.820 we get back from our API server. 00:44.850 --> 00:50.280 So one of the things that we mentioned with Redux best practices is that reducers must not have side 00:50.280 --> 00:51.090 effects. 00:51.750 --> 00:54.810 So we can't inside a reducer when we want to. 00:54.840 --> 00:57.330 Let's say we're updating a product. 00:57.990 --> 01:03.150 We can't dispatch an action to update a product in our store, and then send off a request to our API 01:03.180 --> 01:04.470 to update it. 01:04.470 --> 01:11.550 On the API side, that's a no no because Redux is a synchronous store. 01:11.550 --> 01:15.660 It's designed for synchronous code, not asynchronous code. 01:16.680 --> 01:20.610 But surely a common use case would be to do something that I just described. 01:20.610 --> 01:26.940 We've updated a product on our client, and we need to notify our API and effectively get our Redux 01:26.940 --> 01:31.140 store in sync with what's going on on our API server. 01:31.140 --> 01:34.920 And there was a tool that we could use to do this. 01:34.950 --> 01:42.480 It was called a thunk, and a thunk was a function that is returned by another function and can be executed 01:42.480 --> 01:43.200 later. 01:43.200 --> 01:45.360 And this is how we would get around that. 01:45.360 --> 01:52.050 So in Redux, a thunk would allow action creators to return a function instead of just a plain object, 01:52.050 --> 01:56.430 and then that function can be executed to go and do something with our API. 01:56.460 --> 01:59.850 And this is how I approached it in the previous version of the training course. 01:59.850 --> 02:05.970 But the problem with this approach, as good as Redux toolkit, is at reducing boilerplate code. 02:05.970 --> 02:11.620 As soon as we introduced this, we would start introducing boilerplate into our code. 02:11.650 --> 02:19.000 So just as an example of how we did it previously, we'd create a thunk using the create async thunk, 02:19.030 --> 02:21.430 which is still available in Redux Toolkit. 02:21.430 --> 02:26.080 And then in our reducer we would specify extra reducers. 02:26.110 --> 02:31.240 And this is only a small snapshot of the boilerplate for this kind of functionality, because I've only 02:31.240 --> 02:35.020 included two cases the pending and the fulfilled state. 02:35.050 --> 02:37.660 We would also need to handle the error state as well. 02:37.660 --> 02:43.090 So for this single action, in this case fetching a user, we would need 4 or 5 lines of code for the 02:43.090 --> 02:43.780 thunk. 02:43.780 --> 02:50.290 And then we would need about another 8 or 910 lines of code for the extra reducer that we would need 02:50.290 --> 02:51.070 to implement. 02:51.070 --> 02:57.430 And just to give you a picture of how much boilerplate this would create, then this is an example of 02:57.430 --> 03:02.980 how our catalog slice looked inside the original version of this course. 03:02.980 --> 03:08.230 Many, many lines of code when using the Thunks with our Redux store. 03:08.230 --> 03:09.550 So goodbye to that. 03:09.580 --> 03:10.660 We're not touching that. 03:10.690 --> 03:13.300 I'm not even going to demonstrate an example of that. 03:13.870 --> 03:18.290 The code for the previous course is available if you want to take a look and see how to use that. 03:18.290 --> 03:23.360 But I'm not going to cover that in this course because we have RTK query now. 03:23.360 --> 03:26.270 And let's take a look at some of its benefits. 03:26.390 --> 03:29.510 First things first, it reduces boilerplate. 03:29.510 --> 03:36.140 We write a lot less code for the same functionality or more functionality, I should say, because some 03:36.140 --> 03:39.680 of the other benefits it gives us, it gives us data fetching built in. 03:39.710 --> 03:45.350 Again, in the previous version of this course, I used a data fetching library called Axios that really 03:45.350 --> 03:48.470 is just a data fetching library, and it doesn't integrate with Redux. 03:48.470 --> 03:53.960 So we end up using the Thunks and Axios and then updating our Redux store manually. 03:53.960 --> 03:56.630 Based on what we get back from our API. 03:56.660 --> 03:59.660 RTK query comes with data fetching built in. 03:59.660 --> 04:02.060 It also comes with excellent TypeScript support. 04:02.090 --> 04:05.600 Of course, we're writing our code in TypeScript, so we benefit from that. 04:05.600 --> 04:09.260 And it also provides us with the ability to use optimistic updates. 04:09.260 --> 04:15.560 So user does something in the user interface that requires us to update our API. 04:15.920 --> 04:18.320 We can update the user interface immediately. 04:18.320 --> 04:21.170 Then in the background do something with our API. 04:21.170 --> 04:24.150 And if all goes swimmingly well, then great, nothing changes. 04:24.150 --> 04:30.150 But if it all goes horribly wrong, then the update is rolled back and the browser user interface is 04:30.150 --> 04:33.960 rolled back to what it was before the update was applied. 04:34.110 --> 04:36.210 We also get automatic caching. 04:36.210 --> 04:42.660 This is a huge benefit because writing the code to cache things that come back from our API on our client 04:42.660 --> 04:45.450 side is quite burdensome for a developer. 04:45.450 --> 04:52.410 This handles caching automatically, and caching is the number one, two and three way that we can improve 04:52.410 --> 04:55.440 performance or perceived performance in our application. 04:55.440 --> 05:01.170 So caching is definitely something we would want to add and it's server state focused. 05:01.170 --> 05:07.980 So RTK query is focused on keeping our store in sync with server state. 05:07.980 --> 05:13.890 And what we also get with RTK query is built in middleware, which provides a whole range of functionality 05:13.920 --> 05:16.170 from the automatic cache management. 05:16.170 --> 05:19.740 It also deals with request De-duplication. 05:19.740 --> 05:25.830 So if multiple different components are triggering the same query with identical parameters, the middleware 05:25.830 --> 05:29.680 ensures that only one network request is sent. 05:29.710 --> 05:37.030 It also handles things like state management, so it listens for query and mutation actions, such as 05:37.030 --> 05:42.760 when a fetch is started, when it's been fulfilled, when it's been rejected, so that we can use that 05:42.760 --> 05:45.160 functionality to display a loading indicator. 05:45.160 --> 05:48.580 And the middleware also handles error handling as well. 05:48.580 --> 05:55.210 So a huge range of functionality and just a quick overview of how we use it before we use it. 05:55.270 --> 06:02.290 We use the create API functionality from Redux Toolkit, and then we define endpoints and the queries 06:02.290 --> 06:03.340 we wish to go. 06:03.370 --> 06:13.510 What we also get with this is we get hooks automatically generated by RTK query as well, that we can 06:13.540 --> 06:15.970 then simply use in our component. 06:15.970 --> 06:21.070 And the hook that automatically gets generated for us contains the data that's coming back from the 06:21.070 --> 06:21.910 API. 06:22.210 --> 06:23.230 Any errors. 06:23.230 --> 06:26.890 And also we can get the loading state from that as well. 06:26.890 --> 06:33.640 So basically it's an incredibly powerful and useful tool that we're now going to implement in our application.