Okay.
So for some of these errors we might want to redirect them such as a 404 error.
Then we might want to redirect them to a not found page.
In the case of a 500 error, we might want to redirect them to a server error page and display something
there that tells them that something's gone wrong with our server side.
Well, we wouldn't be specific about what went wrong.
We would just tell them that an unexpected problem has occurred, for example, the validation error.
We'd probably want to display.
Typically, we encounter a validation error with a form.
So we might want to display that on the component itself.
But things like the 400 error for a bad request or an unauthorized, we might want to just display a
toast to the user that something has happened and keep them on the same component that they're on.
So we'll do that for a couple of the errors and the package we'll use this to help us with toasts is
called react testify.
And if I take a look at NPM then this is the kind of thing that it gives us.
Very simple to use.
and we can use these toasts anywhere we want and display a notification to the user.
So we're going to go ahead and install this into our project.
So installation is just npm install react to justify this save flag by the way.
It's no longer required.
It doesn't do any harm if we do use it.
But once upon a time we did have to specify save if we wanted our package.json to be updated after we
npm install something.
So you still see this sometimes, but it's not required when we use npm install to add a package.
So let's go back to vs code and we'll go to the third tab I'm using to install things into the client.
And I'll just paste in the npm install.
And like I say we don't need that save.
But it doesn't do any harm.
But what will probably happen, let's see, is I've still got to use the legacy peer dependency, which
seems to be a common thing, and it will probably be for every single package.
We just need to add the legacy peer dependencies switch here.
So I'll just repeat the command and paste on the legacy peer deps and press return.
And like I've said before, of course if you're on a stable version of react 19 or you're using react
18, then you won't need that switch.
So now that is available to us, we will first of all set up our toast provider.
We want to use toasts from anywhere.
So I'll close this stuff down and let's open up our main dot TSX, the entry point for our application.
And we add this at the highest level so that we've got access to toasts and can use them from anywhere
in our react application.
So just above the router provider here I'm going to specify toast container which we get from react
to justify and make it self-closing.
And we can give this a position property.
Where do we want the toasts to display?
And I'm going to say bottom dash.
Right.
And it typically comes with a progress bar.
How long is the toast going to be on the screen for?
I don't particularly like that.
So I'm going to hide the progress bar and I'm going to give it a theme of colored.
So an error would be colored in red, a success would be colored in green.
So that's what I'm going to go for there.
So where are we going to use these toasts.
Well we're going to go to our central place, the base API TS and where we've got our check to see if
we've got an error, any errors that come back from our API.
We're going to use this condition to check what kind of error it is, and then do something based on
that error.
So instead of this console.log here that's below this we'll add a switch.
So let's use the switch statement snippets and we can give it a key.
And the key is going to be on the status.
And in the case of a 400 then we can specify toast dot error.
And we can pass in the data as the error message.
And we've got a warning here saying argument of type unknown is not assignable to parameter of type
toast content.
Our toast expects a string and it doesn't know what format this data is in, but it should be a string,
so we can just specify as string to take away the warning there.
Now, I know based on how we saw the format of this 400 error in the logs, this is not going to do
what we expect it to do.
And in fact, I'm just going to add back in the console dot log the status and the data, because I
think we're going to need to go and take a look at what we do get back from this, and in fact, not
the object there.
I'm actually going to console dot log the results dot Don't error.
I want to take a look at the whole object of what happens when we encounter an error in RTK query,
and just for comparison.
So we've got something to compare it to.
I'm just going to add the case of a 401.
I'm going to add the total error and again say data as string because that one didn't have.
And I'm missing a semicolon at the end there because the 401 didn't have the same parsing error that
we saw before.
And I'll just add a break statement there and that should be fine.
Okay.
So that gives us enough to start testing with.
So let's head back to the browser and go back to our application.
I'll just refresh the page.
And first of all, if we click on the test 400, error doesn't seem to happen or we certainly don't
see the toast I should say.
And if I click on the test 401 error, we still don't see the toast.
But I have forgotten to add something crucial into our main TSX where we added the toast provider.
This does come with CSS that we need to include in our application.
So below the toast container I'm just going to import.
And we need react dash testify forward slash dist.
And that's interesting.
It used to come from a dist folder.
But my intellisense here or autocomplete is telling me it comes from somewhere else.
So this is going to be one of those few occasions where I want to double check what's going on in node
modules to see the physical file path of the CSS, because VSCode is telling me one thing, and previously
this was in a different location, this CSS file.
So I'm just going to go into node modules huge folder and find react testify.
And sure it is in a dist folder and it's in the dist folder we need to get the CSS from.
So VSCode is wrong, my notes are correct and I need to specify forward slash dist Fast forward slash.
And then we're going to use react to defeat CSS there.
Okay.
So let's go back to the browser and give this another go.
I was expecting a problem with the 400 error one anyway and not display the toast.
And if I do the 401 error then I'm still not seeing the toast.
But if I go and take a look at the data.
Well, data is an object and our toast cannot handle an object.
It has to be a string.
So we need to go and get the title from this.
So one more trip back to VS code.
And this needs to be data dot title and not as string.
And we're getting some warnings here.
So we've got some TypeScript shenanigans that we need to deal with with this.
But this should still work even with the warning.
It's just telling us that data is unknown.
So we've got some TypeScript stuff to deal with here with how the responses are coming back from our
API.
But this should work regardless of the warning.
So let's give this another go.
If I test the 401 error, then this time I do see the unauthorized popping in.
But if I check the 400 error, then what do we see?
Nothing.
Okay, so we've got some work to do here, but we can confirm, at the very least, that our test package
is working.
What we'll need to look at next is this status of parsing error.
And what we get back from react query for this particular type of error.
And we're going to need to do some TypeScript jiggery pokery to get this to work.
So if we take a look at what we've got coming back for the 400, let's just take a quick look at how
we can deal with this, because this is what we're logging out for the resulting error in our base API
query.
So we've got the data.
That's fine.
We've got the error saying that this is not valid JSON.
And we've got a status of parsing error.
But we do have the original status of 400.
So we could use that to check.
And if it is the original status of 400, then we can use a combination of that number and the data
to get the result that we're looking for.
So let's just head back to VS code and make another small change inside here just to correct that particular
issue.
And instead of using const and destructuring the status and the data inside here let's do something
slightly different.
So I'm going to say const original status equals results dot error dot status is equal to passing error.
And we have a result dot error dot original status.
If both of those conditions are true then we'll just use a ternary and we'll say results dot error dot
original status.
Because we don't want the status with passing error.
We want the 400 contained there.
Otherwise we don't have a passing error and we can set the original status to result dot error dot status.
And then instead of using status here, we can use the original status as we've got it above and we
can get the data.
So just above the switch there I'm going to say const response data equals result dot error dot data.
And then I will use the response data inside here.
And for the 401 instead we'll use response data dot title.
We're still going to have the same warning but it should have the correct functionality now.
So let's just go back take a look.
I'll just refresh the page.
What we should find is we get the toast for the bad request, correctly saying this is not a good request,
and we should still have the 401 error functionality working as well.
So great.
But we've got a bit of awkward code in here.
We've got a TypeScript warning, and we're going to need to enhance our usage of TypeScript here to
handle this a bit better.
And we'll take a look at that next.