WEBVTT 00:00.350 --> 00:04.340 Okay, so now we're making use of RTK query and we're making progress. 00:04.340 --> 00:07.670 But everything's happening a bit too quickly for our liking. 00:07.700 --> 00:10.340 Well that's not something we would typically say. 00:10.340 --> 00:14.600 But when we're in development, obviously we've got an understanding that everything's running on our 00:14.600 --> 00:15.290 local machine. 00:15.290 --> 00:21.410 There's no network to traverse, so we get the super fast application experience. 00:21.410 --> 00:26.510 But obviously when we publish onto the big bad world of the internet, then there's going to be network 00:26.540 --> 00:32.150 to traverse, and that means latency and our request will not be quite as fast. 00:32.150 --> 00:35.630 So we're going to add some fake delay into our application. 00:35.630 --> 00:43.220 And we'll also take the opportunity to make a custom base query instead of using the fetch based query 00:43.220 --> 00:47.570 that comes from RTK query, we can create our own. 00:47.570 --> 00:53.360 And we can use this as a centralized place to carry out things like error handling, and also for things 00:53.360 --> 00:55.190 like loading indicators as well. 00:55.190 --> 00:58.400 So let's go and configure this in our application. 00:58.520 --> 01:02.510 And inside the let's clean things up at the top first of all. 01:02.510 --> 01:06.710 And inside the app folder I'm just going to create a new folder called API. 01:06.730 --> 01:10.240 And inside this folder I'm just going to right click say New File. 01:10.240 --> 01:13.870 And I'm just going to call it base API dot BTS. 01:13.870 --> 01:20.890 And then inside here we're going to create a const called custom base query. 01:21.310 --> 01:24.100 And we're going to set it equal to the fetch base query. 01:24.100 --> 01:27.160 And inside here we can make some adjustments to it. 01:27.160 --> 01:29.950 But first of all let's specify the base URL. 01:29.950 --> 01:33.730 And still just for the short term I'll just hard code this in here. 01:33.730 --> 01:38.470 But this is the only place where we're going to have this hardcoded URL. 01:38.650 --> 01:42.880 So I'm going to specify localhost 5001 forward slash API. 01:42.880 --> 01:48.430 And when we do add this to our configuration, this is the only place that we're going to need to adjust 01:48.430 --> 01:49.990 that hardcoded URL. 01:50.020 --> 01:51.850 So it's not too big of a deal at the moment. 01:51.850 --> 01:57.370 Whilst we're still developing our application, I'm also going to create a sleep function so that we 01:57.370 --> 02:00.460 can add some fake delay into our query. 02:00.460 --> 02:05.680 So I'm going to create const sleep and I'll just use an arrow function for this. 02:05.680 --> 02:07.030 So it doesn't take any parameters. 02:07.030 --> 02:08.230 And we add the arrow. 02:08.260 --> 02:11.290 And this is going to return a new promise. 02:11.680 --> 02:20.640 And we say resolve as our promises will resolve, and then we can use the setTimeout function and pass 02:20.640 --> 02:22.950 in resolve what we're returning from our API. 02:22.980 --> 02:31.140 When we use this, and we can give this a delay of 1000, which is 1000 milliseconds, which is a second. 02:31.470 --> 02:36.990 And let's create our custom base query that we're going to use for our request. 02:37.020 --> 02:43.410 So I'm going to say export const and I'm going to call it base query with error handling. 02:44.070 --> 02:47.430 And once again we'll use an arrow function for list. 02:47.430 --> 02:51.630 And we're going to make this an asynchronous request. 02:51.630 --> 02:54.960 And doing this guarantees that it's going to return a promise. 02:54.990 --> 02:56.610 So I'm going to say async. 02:57.030 --> 02:58.800 So we need to give this some arguments. 02:58.800 --> 03:06.390 And what I'll fetch base query expects it expects some fetch arguments and it expects some options as 03:06.390 --> 03:07.200 well. 03:07.470 --> 03:10.890 So let's add this now our arguments. 03:10.920 --> 03:14.070 I'll specify args and this could be a string. 03:14.070 --> 03:16.020 Or we'll use a union type. 03:16.020 --> 03:20.690 This could be fetch args that we get from Redux Toolkit. 03:20.720 --> 03:23.390 And the next argument is API. 03:23.420 --> 03:26.240 And this is going to be the base query API. 03:26.270 --> 03:28.610 Again we get this from Redux Toolkit. 03:28.640 --> 03:33.230 And we'll pass in an argument for extra options. 03:33.230 --> 03:36.950 And we'll just specify object as the type for this. 03:36.980 --> 03:40.130 And then we'll add the arrow and open curly brackets. 03:40.160 --> 03:41.780 And I've gone way off the edge of the screen there. 03:41.780 --> 03:44.330 So let's move some of this down. 03:44.360 --> 03:51.290 So inside the curly brackets then inside the body of this the first thing we're going to do is start 03:51.320 --> 03:53.030 loading effectively. 03:53.510 --> 03:55.370 But we don't have that functionality yet. 03:55.370 --> 04:01.130 So I'm just going to say await sleep and call our sleep function, which is going to delay our request 04:01.130 --> 04:02.780 by a second. 04:02.810 --> 04:06.230 Then we're going to say const results equals await. 04:06.230 --> 04:10.250 And we're going to use our custom base query we created above. 04:10.610 --> 04:15.350 We're going to pass in the arg the API and the extra options. 04:15.350 --> 04:20.840 And then I'll just add a comment to say at this point we're going to stop our loading indicator. 04:20.870 --> 04:23.510 Again we don't have that functionality yet. 04:23.660 --> 04:28.410 And then we're going to check to see if the result has an error though. 04:28.410 --> 04:32.610 We get back from our API and at this point we can start to think about error handling. 04:32.610 --> 04:34.650 Now we're not going to do anything significant yet. 04:34.650 --> 04:36.750 We're just really going to log out to the console. 04:36.900 --> 04:40.590 But we can destructure what we get from the result dot error. 04:40.590 --> 04:44.730 So I'm going to say const curly brackets and then say result dot error. 04:45.330 --> 04:52.410 And inside the curly brackets we've got access to the status and the data from the error. 04:52.410 --> 05:02.520 And all we'll do for now is we'll just use console dot log and output the object of the status and the 05:02.520 --> 05:03.420 data. 05:03.480 --> 05:09.030 So inside curly brackets we'll just output that to the console and below the if statements. 05:09.030 --> 05:12.570 If we do not have an error then we're just going to return the result. 05:13.080 --> 05:14.640 So this is our custom base query. 05:14.640 --> 05:21.030 And we're going to use this in place of the fetch base query that we used in our catalog API. 05:21.060 --> 05:23.760 So let's open up the catalog API. 05:23.790 --> 05:26.760 And we use the fetch base query here. 05:26.760 --> 05:35.270 And instead of using this because we have our base URL specified in the custom query that we've created. 05:35.300 --> 05:44.540 We can use the base query with error handling as the base query, and we can remove the fetch base query 05:44.540 --> 05:45.830 at the top here. 05:45.860 --> 05:52.250 So what we should have done now by changing this to use this base query is slow our application down. 05:52.250 --> 05:57.350 If we go and take a look and I go back to the catalog, then we see our loading and it stays there for 05:57.350 --> 05:58.070 a little while. 05:58.070 --> 06:00.500 That one's already in cache, so that's fine. 06:00.500 --> 06:05.570 If I pick a different one we see loading, we go back to the catalog and have picked a different one. 06:05.570 --> 06:12.260 We can definitely see our application has slowed down now, apart from when we're retrieving the elements 06:12.260 --> 06:18.860 from cache, and then it still loads instantly, but it would be nice to inform the user that some loading 06:18.860 --> 06:20.480 is taking place. 06:20.480 --> 06:27.080 And what we'll take a look at next is configuring our application so that we can centralize loading 06:27.080 --> 06:32.360 state when a query is going out to our API, and display something to the user to let them know that 06:32.360 --> 06:36.380 something is loading and their computer hasn't just frozen. 06:36.380 --> 06:38.720 And we'll take a look at that next.