Beautiful.
We now know how we can set up the instance in Axios and we'll definitely use it for remaining.
Our project are fetch, but we're not going to keep the headers here.
Now technically you can leave them, but since I want to showcase the interceptors in action, actually
move them to the interceptors and before you freak out about the name.
Effectively.
Our current setup is awesome, but unfortunately it still does not give me a way to handle 401 responses,
meaning the authentication errors programmatically.
And yes, of course I will discuss that in way greater detail later as we actually start setting up
the code in the interceptor.
But just to give you an overall picture, remember, we're getting this error and then that response.
And what we need to keep in mind is that there is a huge difference between a 400 response and 401.
Because we know that 400 is bad request where 401 is actually authentication error.
And if we get better, I mean our response on the front end should be also different.
And at the moment, if I'll start setting everything up again, I'll have to copy and paste and I don't
think I need to tell you that that's probably not the best approach.
Now, what is a better approach?
Well.
In Axios, there's something called interceptors.
Now, don't freak out about the name.
Essentially what it means is that you can attach some functionality as your request leave the application
and as the requests are coming back.
So in a way, you can think of it as a middleware, just like we were setting this up in the Mongoose.
Now, in our examples, we'll be attaching this to our custom instance, because I already have that
base URL and everything is in place.
Keep in mind you can still use it with Axios.
So let's say you don't want to set up the custom instance.
You can simply go with Axios and then the code essentially is exactly the same.
A quick update.
In the current Axios version, the common property returns undefined.
So the correct code is headers and then we straight away need to go for authorization header.
Basically, we need to omit the common property.
If you need a reference, read me contains the correct code and let me just showcase what they're saying
here in the docs.
So notice we can add a request interceptor as well as the response one.
And the syntax is Axios interceptors request.
So this is of course for requests one and the response will be for response one.
Then they go with use.
That's why I said that it's pretty much like a middleware here, and then we pass in two functions.
So the first function we do something before is sent, which in our case is going to be what?
Well, adding those headers.
Correct.
And then we can do something if there is a error.
And as far as default, you can go promise, date, reject, and then you have the same thing for the
response one and notice what's really cool.
So in here they have a function and a status code that lie within range of 200.
This function will be triggered, correct?
So this is going to be the successful one.
Now, we don't need to worry about that one time one will handle in our functions.
Now what is super, super, super useful in our case that we have the second function which will be
triggered if any status code falls outside of 200.
So this is where we'll set up that logic where if it is for a one, well then maybe a good idea is to
actually log out the user.
And yes, I know I'm skipping a little bit.
I've had, but I just want to give you the overall picture where essentially as our request leaves,
we will set up that header.
The authorization again will do that on the instance.
And the second thing we'll do will check for those 401 errors.
And if they're present, then we'll take, let's say, more forceful action on the front end.
So let's navigate back.
I mean, code is pretty much the resemblance of what you have there in the docs.
And the only difference is that in here I'm adding authorization.
And then as far as this error, I just want to log it.
That's it.
That's all I want to do.