Okay, so now we're making use of RTK query and we're making progress.
But everything's happening a bit too quickly for our liking.
Well that's not something we would typically say.
But when we're in development, obviously we've got an understanding that everything's running on our
local machine.
There's no network to traverse, so we get the super fast application experience.
But obviously when we publish onto the big bad world of the internet, then there's going to be network
to traverse, and that means latency and our request will not be quite as fast.
So we're going to add some fake delay into our application.
And we'll also take the opportunity to make a custom base query instead of using the fetch based query
that comes from RTK query, we can create our own.
And we can use this as a centralized place to carry out things like error handling, and also for things
like loading indicators as well.
So let's go and configure this in our application.
And inside the let's clean things up at the top first of all.
And inside the app folder I'm just going to create a new folder called API.
And inside this folder I'm just going to right click say New File.
And I'm just going to call it base API dot BTS.
And then inside here we're going to create a const called custom base query.
And we're going to set it equal to the fetch base query.
And inside here we can make some adjustments to it.
But first of all let's specify the base URL.
And still just for the short term I'll just hard code this in here.
But this is the only place where we're going to have this hardcoded URL.
So I'm going to specify localhost 5001 forward slash API.
And when we do add this to our configuration, this is the only place that we're going to need to adjust
that hardcoded URL.
So it's not too big of a deal at the moment.
Whilst we're still developing our application, I'm also going to create a sleep function so that we
can add some fake delay into our query.
So I'm going to create const sleep and I'll just use an arrow function for this.
So it doesn't take any parameters.
And we add the arrow.
And this is going to return a new promise.
And we say resolve as our promises will resolve, and then we can use the setTimeout function and pass
in resolve what we're returning from our API.
When we use this, and we can give this a delay of 1000, which is 1000 milliseconds, which is a second.
And let's create our custom base query that we're going to use for our request.
So I'm going to say export const and I'm going to call it base query with error handling.
And once again we'll use an arrow function for list.
And we're going to make this an asynchronous request.
And doing this guarantees that it's going to return a promise.
So I'm going to say async.
So we need to give this some arguments.
And what I'll fetch base query expects it expects some fetch arguments and it expects some options as
well.
So let's add this now our arguments.
I'll specify args and this could be a string.
Or we'll use a union type.
This could be fetch args that we get from Redux Toolkit.
And the next argument is API.
And this is going to be the base query API.
Again we get this from Redux Toolkit.
And we'll pass in an argument for extra options.
And we'll just specify object as the type for this.
And then we'll add the arrow and open curly brackets.
And I've gone way off the edge of the screen there.
So let's move some of this down.
So inside the curly brackets then inside the body of this the first thing we're going to do is start
loading effectively.
But we don't have that functionality yet.
So I'm just going to say await sleep and call our sleep function, which is going to delay our request
by a second.
Then we're going to say const results equals await.
And we're going to use our custom base query we created above.
We're going to pass in the arg the API and the extra options.
And then I'll just add a comment to say at this point we're going to stop our loading indicator.
Again we don't have that functionality yet.
And then we're going to check to see if the result has an error though.
We get back from our API and at this point we can start to think about error handling.
Now we're not going to do anything significant yet.
We're just really going to log out to the console.
But we can destructure what we get from the result dot error.
So I'm going to say const curly brackets and then say result dot error.
And inside the curly brackets we've got access to the status and the data from the error.
And all we'll do for now is we'll just use console dot log and output the object of the status and the
data.
So inside curly brackets we'll just output that to the console and below the if statements.
If we do not have an error then we're just going to return the result.
So this is our custom base query.
And we're going to use this in place of the fetch base query that we used in our catalog API.
So let's open up the catalog API.
And we use the fetch base query here.
And instead of using this because we have our base URL specified in the custom query that we've created.
We can use the base query with error handling as the base query, and we can remove the fetch base query
at the top here.
So what we should have done now by changing this to use this base query is slow our application down.
If we go and take a look and I go back to the catalog, then we see our loading and it stays there for
a little while.
That one's already in cache, so that's fine.
If I pick a different one we see loading, we go back to the catalog and have picked a different one.
We can definitely see our application has slowed down now, apart from when we're retrieving the elements
from cache, and then it still loads instantly, but it would be nice to inform the user that some loading
is taking place.
And what we'll take a look at next is configuring our application so that we can centralize loading
state when a query is going out to our API, and display something to the user to let them know that
something is loading and their computer hasn't just frozen.
And we'll take a look at that next.