1 00:00:01,660 --> 00:00:03,310 Our air handler is looking pretty good. 2 00:00:03,520 --> 00:00:08,470 We can now very easily make a request that results in air in any time we do we get back a message that 3 00:00:08,470 --> 00:00:10,800 says something like something went wrong. 4 00:00:10,800 --> 00:00:14,340 Now this definitely works but there's definitely a downside to this approach. 5 00:00:14,500 --> 00:00:19,300 Right now we are not really communicating a lot of information back to the user about exactly what just 6 00:00:19,300 --> 00:00:20,210 went wrong. 7 00:00:20,230 --> 00:00:22,530 We are only saying something went wrong. 8 00:00:22,900 --> 00:00:29,500 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 9 00:00:29,500 --> 00:00:33,700 take a look at our sign up request handler right now if we imagine that there's something wrong connecting 10 00:00:33,700 --> 00:00:41,280 to the database I want to tell the user about exactly what just went wrong not just something went wrong. 11 00:00:41,440 --> 00:00:46,150 So we need to somehow consume some more information out of all these different errors that we are throwing 12 00:00:46,390 --> 00:00:50,150 inside of our air middleware handler to do so. 13 00:00:50,150 --> 00:00:53,730 I'm gonna go back over to my ear middleware handler but here it is right here. 14 00:00:53,740 --> 00:00:55,740 I'm gonna find where we set the message. 15 00:00:55,840 --> 00:01:01,000 I'm going to remove something went wrong and I will replace it with air dot message. 16 00:01:01,000 --> 00:01:02,200 Like so. 17 00:01:02,410 --> 00:01:04,030 So what does this right here. 18 00:01:04,030 --> 00:01:09,520 Well back inside of our sign up request handler whenever we create a new air and through it whatever 19 00:01:09,520 --> 00:01:14,800 string we provide as the first argument to that constructor is assigned to the message property of the 20 00:01:14,800 --> 00:01:15,810 air. 21 00:01:16,060 --> 00:01:17,720 So we are creating a new air right here. 22 00:01:17,740 --> 00:01:19,230 This string is going to be used. 23 00:01:19,270 --> 00:01:24,970 It's going to be assigned to the message property so over inside of our middleware. 24 00:01:24,970 --> 00:01:30,610 By setting message to airport message we're going to see whatever string we gave to the air when we 25 00:01:30,610 --> 00:01:31,480 threw it. 26 00:01:31,540 --> 00:01:36,320 And so that should hopefully tell the user a little bit more information about what just went wrong. 27 00:01:36,320 --> 00:01:40,170 So if I save this I will note now go backward a postman. 28 00:01:40,240 --> 00:01:41,310 Send this in again. 29 00:01:41,560 --> 00:01:48,080 And now I'm being told that the request failed because I have an invalid e-mail or password if I update 30 00:01:48,080 --> 00:01:52,700 the e-mail right here and make it valid instead and then send the request again. 31 00:01:52,700 --> 00:01:57,530 Now I am told you're connecting to the database so it's clear that we can definitely communicate a lot 32 00:01:57,530 --> 00:02:04,140 more information from our request handler to our air handler middleware by attaching that information 33 00:02:04,200 --> 00:02:06,310 to the air object in some way. 34 00:02:06,570 --> 00:02:09,290 All right now we are really just limited to that message property. 35 00:02:09,360 --> 00:02:16,040 In other words we are really limited to a simple string ideally we would send back a lot more information 36 00:02:16,040 --> 00:02:18,430 to the user than just that simple string. 37 00:02:18,440 --> 00:02:23,870 So for example whenever we fail validation on that incoming request using that express validate or library 38 00:02:24,170 --> 00:02:29,970 remember we get back an array of objects and those objects describe exactly what property about the 39 00:02:30,020 --> 00:02:31,380 failed validation. 40 00:02:31,460 --> 00:02:35,350 And it also provides a message about what went wrong and how to fix it. 41 00:02:35,360 --> 00:02:41,330 So ideally when we throw in air object we would take the results of the Express validator step and somehow 42 00:02:41,360 --> 00:02:43,530 attach it to that air object. 43 00:02:44,000 --> 00:02:48,470 If we could do something like that then we can teach our error handling middleware to take that array 44 00:02:48,470 --> 00:02:56,190 of objects formatted in some nice way and continue to send back some well structured response. 45 00:02:56,210 --> 00:03:00,350 Now if we are using plain javascript this would be pretty easy to do. 46 00:03:00,350 --> 00:03:06,420 Let me show you one possible solution if again we were using just plain javascript. 47 00:03:06,430 --> 00:03:12,950 So back inside my sign up or out handler I'm going to pretend for a second that this is javascript land 48 00:03:14,100 --> 00:03:20,510 not typescript so if we were in JavaScript land right now we could write out something like concert 49 00:03:20,570 --> 00:03:27,330 air is a new air and I can say invalid email or password as before. 50 00:03:28,780 --> 00:03:34,570 I could then take that airs a rate that we had produced previously and we could do something like air 51 00:03:34,660 --> 00:03:36,400 dots reasons. 52 00:03:36,430 --> 00:03:42,360 Totally made up property off the top of my head and we can assign that the heirs array. 53 00:03:42,400 --> 00:03:48,650 Technically it would be heirs dot to array so now we're sue me to simply write. 54 00:03:48,770 --> 00:03:52,230 So now we're going to take that heirs that we got back from the validation result. 55 00:03:52,280 --> 00:03:57,680 We're going to turn it into the array of objects and then we will assign it to this new imaginary reasons 56 00:03:57,740 --> 00:04:06,440 property we can then throw that error instead of creating a new one on the fly if we assigned or took 57 00:04:06,440 --> 00:04:11,360 this air stuff and assign it to this reason's property we can then access that reason's property inside 58 00:04:11,360 --> 00:04:17,220 of our air handler we could then iterate over that array of objects allowed all the reasons that the 59 00:04:17,220 --> 00:04:22,190 stuff failed so it would be messages like say email must be valid password must be between four and 60 00:04:22,190 --> 00:04:27,380 20 characters and so on and send that back to the user so something like this right here. 61 00:04:27,380 --> 00:04:31,970 This would be kind of ideal this would give us the ability to share a lot more information about what 62 00:04:31,970 --> 00:04:38,220 just went wrong with the user compared to what we have right now however this is not javascript land. 63 00:04:38,230 --> 00:04:44,650 We are writing TypeScript and we cannot just assign magic properties made up on the fly to any old object 64 00:04:44,650 --> 00:04:50,590 that we want to assign stuff to an error in JavaScript and in typescript does not have a reason's property 65 00:04:50,990 --> 00:04:54,630 and so typescript is saying sorry but this is property just doesn't exist. 66 00:04:54,640 --> 00:04:56,720 You cannot assign something to it. 67 00:04:57,130 --> 00:05:01,960 So it's clear that we need to somehow communicate a lot more information from the request handler to 68 00:05:01,960 --> 00:05:03,470 the air handler. 69 00:05:03,640 --> 00:05:08,470 We have to do it using the air object but we cannot really use this very simple and straightforward 70 00:05:08,470 --> 00:05:08,860 approach. 71 00:05:08,860 --> 00:05:14,220 We have to do something a little bit more typescript D so to speak so I'm going to say this we're gonna 72 00:05:14,230 --> 00:05:18,370 take a quick pause right here and the next video I'm gonna show you how we're going to use typescript 73 00:05:18,400 --> 00:05:22,780 to essentially do this but in a much more typescript style fashion.