Our air handler is looking pretty good.
We can now very easily make a request that results in air in any time we do we get back a message that
says something like something went wrong.
Now this definitely works but there's definitely a downside to this approach.
Right now we are not really communicating a lot of information back to the user about exactly what just
went wrong.
We are only saying something went wrong.
So I want to make sure that if a user enters in say an invalid e-mail or an invalid password or if we'd
take a look at our sign up request handler right now if we imagine that there's something wrong connecting
to the database I want to tell the user about exactly what just went wrong not just something went wrong.
So we need to somehow consume some more information out of all these different errors that we are throwing
inside of our air middleware handler to do so.
I'm gonna go back over to my ear middleware handler but here it is right here.
I'm gonna find where we set the message.
I'm going to remove something went wrong and I will replace it with air dot message.
Like so.
So what does this right here.
Well back inside of our sign up request handler whenever we create a new air and through it whatever
string we provide as the first argument to that constructor is assigned to the message property of the
air.
So we are creating a new air right here.
This string is going to be used.
It's going to be assigned to the message property so over inside of our middleware.
By setting message to airport message we're going to see whatever string we gave to the air when we
threw it.
And so that should hopefully tell the user a little bit more information about what just went wrong.
So if I save this I will note now go backward a postman.
Send this in again.
And now I'm being told that the request failed because I have an invalid e-mail or password if I update
the e-mail right here and make it valid instead and then send the request again.
Now I am told you're connecting to the database so it's clear that we can definitely communicate a lot
more information from our request handler to our air handler middleware by attaching that information
to the air object in some way.
All right now we are really just limited to that message property.
In other words we are really limited to a simple string ideally we would send back a lot more information
to the user than just that simple string.
So for example whenever we fail validation on that incoming request using that express validate or library
remember we get back an array of objects and those objects describe exactly what property about the
failed validation.
And it also provides a message about what went wrong and how to fix it.
So ideally when we throw in air object we would take the results of the Express validator step and somehow
attach it to that air object.
If we could do something like that then we can teach our error handling middleware to take that array
of objects formatted in some nice way and continue to send back some well structured response.
Now if we are using plain javascript this would be pretty easy to do.
Let me show you one possible solution if again we were using just plain javascript.
So back inside my sign up or out handler I'm going to pretend for a second that this is javascript land
not typescript so if we were in JavaScript land right now we could write out something like concert
air is a new air and I can say invalid email or password as before.
I could then take that airs a rate that we had produced previously and we could do something like air
dots reasons.
Totally made up property off the top of my head and we can assign that the heirs array.
Technically it would be heirs dot to array so now we're sue me to simply write.
So now we're going to take that heirs that we got back from the validation result.
We're going to turn it into the array of objects and then we will assign it to this new imaginary reasons
property we can then throw that error instead of creating a new one on the fly if we assigned or took
this air stuff and assign it to this reason's property we can then access that reason's property inside
of our air handler we could then iterate over that array of objects allowed all the reasons that the
stuff failed so it would be messages like say email must be valid password must be between four and
20 characters and so on and send that back to the user so something like this right here.
This would be kind of ideal this would give us the ability to share a lot more information about what
just went wrong with the user compared to what we have right now however this is not javascript land.
We are writing TypeScript and we cannot just assign magic properties made up on the fly to any old object
that we want to assign stuff to an error in JavaScript and in typescript does not have a reason's property
and so typescript is saying sorry but this is property just doesn't exist.
You cannot assign something to it.
So it's clear that we need to somehow communicate a lot more information from the request handler to
the air handler.
We have to do it using the air object but we cannot really use this very simple and straightforward
approach.
We have to do something a little bit more typescript D so to speak so I'm going to say this we're gonna
take a quick pause right here and the next video I'm gonna show you how we're going to use typescript
to essentially do this but in a much more typescript style fashion.