Our air handily Middleware is now aware of the type of error that is dealing with.
So now we need to inspect each of these different errors somehow formulate a response and send it back
to the user.
But as a quick reminder the entire reason we got into this entire discussion was we wanted to make sure
that all these different services and all these different kinds of errors are always gonna result in
the exact same structure of air.
We never actually sat down and discussed exactly what the structure of that response should look like.
So let's do that right now.
This is going to be the common response structure for all ears that we have inside our application.
So no matter what the air is no matter the reason for it no matter the server that it is read coming
from we're always going to send back an object that has an errors property and then inside there is
going to be an array of objects each of those objects will have a message that describes the error that
occurred and optionally we'll have a field that refers to the what this error is tied to.
So for example if there's an issue with some email address we would have a field of email and a message
of invalid email or something similar to that.
Now note that this is in kind of typescript interface syntax right here.
You'll notice the empty brackets that I have right here.
That means that this object is going to be a array of objects with that exact structure.
So errors is going to be an array of objects and each of those objects are required to have a message
property that is a string and possibly optionally a field that is a string as well.
So again this is the common structure we're going have everywhere inside of application or errors of
course so when we talk about doing some actual handling or generation of response inside of our area
handling middleware we're not actually just going to take the reasons property off of say the request
validation error or just the reason property off the database connection error.
Instead we want to make sure that we take these errors.
The reason or messaging around them and form them all into this common response structure.
So let's try doing that right now back inside of our middleware but here's our middleware.
We need to go round to each of these different if statements.
So if statement 1 and if statement 2 we're going to take a look at the error that just appeared instead
of our middleware we're going to extract some details about that error.
We're going to massage them essentially or transform them into this exact format right here and then
send the response back to the user.
So we're going to first start off with our instance of right here of request validation error.
Let's get a quick reminder on what all the different error messaging inside there looks like.
So I can go to the definition of request validation error and as you'll recall this thing is going to
have an heiress property assigned to it.
That's going to be an array of validation error and a validation error if we hover over it.
You'll recall as a parent property a message location and value so we need to take this heirs array
right here and we're going to transform it into this structure right here.
That's what we have to do back inside of our middleware so inside my middleware I'm going to first define
a variable called formatted ears and I'll get that from air.
So that's our request validation error dot errors dot map so we will map over each error and for each
error we're going to make sure that we return an object that has a message and possibly a field as well
so I will return message the value from that is going to come from air dot message and field and the
value for that will come from air dot RAM
though again just to make sure that step was really clear we took all the errors.
Remember this is the information we wanted to communicate from our root handler over to the area handling
middleware we wanted to take that array of validation errors that we got back from Express validator
and we wanted to transform it into this structure right here and that's what we are doing with this
mapping statement.
So now that we've built out this list of formatted errors we can take it and send it back to the user
but I'll put in a return because we want to return early and not execute anything else inside of here
and we'll do a rez that status of 400 and then we will send an object that has a list of errors as formatted
errors like so.
Just be clear.
I said that we had to transform the errors inside of our request validation error into this structure
right here.
Just be really precise what we really just did with that mapping statement was essentially generate
that array of objects.
And that's why we took the result to that.
So that's the array of objects we threw into this object with errors to make sure that we conformed
to this structure right here all right.
So let's say this will then go over to Bozeman and do a quick test so I want to test out that invalid
request handler and make sure I put in it.
In any event invalid email I'll send this off.
And there we go.
You'll notice that we now have an object that has an airport property and an inside there is an array
of objects each object as a message and possibly a field as well.
So now our response coming back from my area handling middleware when we get a error of type request
validation error is going to always conform to this exact error response structure is remember we want
to make sure that every single error that we ever send back to our ReACT app is always going to follow
this structure.
So the react app does not need to know how to implement 50 different error passing methods okay.
So we're pretty much going to repeat the same exact process or something very similar to it for our
database connection there now.
So in this case I'm going to return early because I don't want to run anything else inside of your I'll
do a red dot status in this case.
It's not really appropriate to use stats go to a four hundred four hundred means bad request which usually
indicates that the user sent us some bad data.
In this case if we have a database connection error that's really indicating that there is something
wrong with our server.
And so we should really use a five hundred status code for that or something similar.
So we could always look up our list of each TTP status codes and it might be a little bit more appropriate
to do something like a 500 error in this case to say a sorry something internally is not quite right
or maybe even a five or three either one.
Totally fine.
Let's just go to 500 in this case and then I'll send again the exact same structure will do errors.
Let's go and get a reminder of all the data that is available to us inside of database connection error.
So go back to that error definition is database connection here right here and you'll recall that in
this case we've got that reason property that is storing the reason that we just threw this database
connection error so in this case we can't send back in array that will create manually inside there.
I'll just give it a message and I'll assign to message E R dot reason like so so again we still have
that same exact structure that we said that we want to have for every single response we've got our
array of objects where each one has a message and possibly a field.
In this case there's no field to tie to our message.
So we are not including that field.
Let's save this.
We'll go back over to postman and do another test go inside a post man I'm going to update my email
again and put in a valid e-mail to make sure that I get the database connection error.
I'll send this off and now we get a 500 Internal Server Error.
And I've got the exact same structure as before.
Awesome the last thing we need to take care of is the final response type right here so if we don't
understand the air that just came in.
If this is just some generic error that we didn't really plan on we still need to make sure that this
follows the same structure that we said we were going to follow for everything else.
So that same kind of errors that's an array of objects.
Right now it's just sending back a single object that has a message.
Property can replace that with errors I'll put in an array.
I'll give it one object with a message and we can either just try to take the message property off the
incoming air or we could put in a more generic thing just something like something went wrong or something
like that okay.
So let's say this and we'll just do one last test.
Even though we don't really have the ability to really test out that final error we'll just send and
make sure that I still have everything working.
Yeah.
Looks like it's still working.
OK.
So at this point time we've now seen kind of the entire start to finish.
We've seen that we wanted to have these very common structures for every single thing that could possibly
go wrong inside our application so that our ReACT application can always take the air and work with
it and somehow without it needing to have a intricate understanding of what's going on behind the scenes
we did this by creating this custom area handling middleware we needed to transfer some very precise
information about all these errors that occurred from the request handler into the error handling middleware
which is why we subclass the air base class into request validation error and database connection error
then anytime that we saw these errors appear inside of our middleware we could check to see if that
errors is of a particular type and if it is then we'll go ahead and interpret that error accordingly.
Again this really is a good example right here.
But we are not quite done yet.
As I mentioned there's still a couple of improvements they're going to throw on top this make it even
easier to use from our different root handlers than what we have right now so still a little bit to
go.
Quick pause right here and we'll continue in just a moment.