1 00:00:01,760 --> 00:00:05,930 As we discussed in the last video let's implement this custom air abstract class. 2 00:00:05,930 --> 00:00:11,360 This is going to extend the base air class we're then going to make sure that request validation air 3 00:00:11,450 --> 00:00:16,580 and database connection air extend custom air instead of the air built in. 4 00:00:16,590 --> 00:00:20,990 So let's get to it back inside my editor off on the air directory. 5 00:00:20,990 --> 00:00:27,020 I'm gonna make a new file inside they're called Custom air Dot T S then inside of here I'm going to 6 00:00:27,020 --> 00:00:37,000 declare a new class new abstract class to be precise so abstract class custom air and this is going 7 00:00:37,000 --> 00:00:44,840 to extend or extends a built in air class then inside of here we're going to list out all the different 8 00:00:44,840 --> 00:00:50,570 properties that must be defined by any class that extends this very similar to how an interface works 9 00:00:50,580 --> 00:00:56,900 remember we write out interfaces and we try to satisfy the interface same thing with abstract classes 10 00:00:57,190 --> 00:01:02,210 or the way in which we write out these properties at subclasses must implement is just slightly different. 11 00:01:02,210 --> 00:01:06,930 We're going to write out abstract status code number. 12 00:01:07,040 --> 00:01:12,620 So this is saying that if you're going to extend customary you gotta have a status code property and 13 00:01:12,620 --> 00:01:16,370 it must be a number by writing out abstract right there. 14 00:01:16,370 --> 00:01:19,870 That's what's saying that a subclass must implement this thing. 15 00:01:20,090 --> 00:01:21,430 So we could test this out right away. 16 00:01:21,470 --> 00:01:29,730 We can say hey let's have a new class right here goes something like not found error and we'll try to 17 00:01:29,730 --> 00:01:33,960 extend estimate right writer way we'll get an error. 18 00:01:34,140 --> 00:01:39,080 It says hey you need to make sure that you implement that status code property. 19 00:01:39,210 --> 00:01:44,610 So if we put inside of your status code for a before it goes away. 20 00:01:44,740 --> 00:01:51,080 So again very similar in nature to a interface but we're using a class instead because that's going 21 00:01:51,080 --> 00:01:55,920 to allow us to carry actual class definition over to the javascript world down. 22 00:01:55,920 --> 00:01:58,900 Next up we will define a constructor. 23 00:01:58,950 --> 00:02:03,180 The only reason we are defining a constructor is to make sure we can put in that special little line 24 00:02:03,180 --> 00:02:04,620 of code that we've seen once or twice. 25 00:02:04,620 --> 00:02:08,900 Now that is required anytime that we are trying to extend a built in class. 26 00:02:09,120 --> 00:02:14,550 So it's that same thing that we wrote out over inside of both database connection error and request 27 00:02:14,550 --> 00:02:15,380 validation error. 28 00:02:15,450 --> 00:02:21,760 Is that object set proto type of thing so back inside of our customer abstract class and make sure I 29 00:02:21,760 --> 00:02:26,130 copy one of those over and we'll make sure that I update the name of the class right there as well. 30 00:02:26,210 --> 00:02:29,890 To customer because we are defining a constructor. 31 00:02:29,900 --> 00:02:35,190 We do have to define super like so. 32 00:02:35,380 --> 00:02:39,940 Then after that let's set up our other method or the other requirement of anything that wants to be 33 00:02:39,940 --> 00:02:41,370 a customer. 34 00:02:41,380 --> 00:02:49,110 So I'm gonna say you must have an abstract method of serialize errors so we're not actually defining 35 00:02:49,140 --> 00:02:52,050 a method here instead we are defining a method signature. 36 00:02:52,050 --> 00:02:58,740 So we're saying that to extend a customer you have to define serialize errors and it must return something 37 00:02:59,130 --> 00:03:06,060 that is going to be an array of objects and each object must have a message that is a string and optionally 38 00:03:06,060 --> 00:03:10,580 can have a field that is a string as well and there you go 39 00:03:15,000 --> 00:03:19,880 so now we can go back around to our other two custom classes though database connection area and request 40 00:03:19,880 --> 00:03:21,070 validation error. 41 00:03:21,100 --> 00:03:26,120 We're gonna make sure that they extend customer and that's going to put in this requirement that they 42 00:03:26,120 --> 00:03:32,480 must implement a status code and serialize with the appropriate signature they'll first go over to database 43 00:03:32,480 --> 00:03:34,160 connection error at the very top. 44 00:03:34,160 --> 00:03:38,930 I'm going to import custom air from customer 45 00:03:41,790 --> 00:03:45,640 now rather than extending the air built in class. 46 00:03:45,660 --> 00:03:51,320 We want this thing to extend custom air like so. 47 00:03:51,380 --> 00:03:56,660 So now if we ever put any type of inside of here if we ever forget to implement status code we're gonna 48 00:03:56,670 --> 00:03:57,630 get there. 49 00:03:57,630 --> 00:04:00,620 If we ever misspell status code we'll get in there. 50 00:04:00,900 --> 00:04:05,430 If we ever return something from serialize theirs that does not have the correct structure like just 51 00:04:05,510 --> 00:04:06,030 m. 52 00:04:06,210 --> 00:04:07,420 We'll get in there. 53 00:04:07,420 --> 00:04:12,570 And so again this is all about making sure that we are implementing these custom air classes correctly 54 00:04:14,720 --> 00:04:19,600 so now we can repeat that same process inside of request validation error as well. 55 00:04:19,600 --> 00:04:27,280 So at the top I'll do an import SDM air from customer and again I'll update that extend statement to 56 00:04:27,280 --> 00:04:29,520 custom air like so. 57 00:04:29,580 --> 00:04:34,950 So again if I forget to implement status code it gets an error if I ever make a typo inside of serialized 58 00:04:34,950 --> 00:04:37,570 errors we get an error as well. 59 00:04:38,670 --> 00:04:39,010 Okay. 60 00:04:39,100 --> 00:04:40,860 Let's say that this is a definite improvement. 61 00:04:40,870 --> 00:04:45,140 It's gonna make sure that we always implement these air classes 100 percent correctly. 62 00:04:45,190 --> 00:04:49,730 All we have to do is remember to import custom air. 63 00:04:49,750 --> 00:04:55,290 We build a class we extend customer and then typescript is gonna take it from there typescript is gonna 64 00:04:55,330 --> 00:04:59,700 tell you hey if you want to be a customer you gotta have that property you've got to have serialize 65 00:04:59,700 --> 00:05:02,010 theirs and you won't need anything else. 66 00:05:02,080 --> 00:05:05,690 Any other information to understand how to do this stuff or how to actually build out of custom air 67 00:05:05,710 --> 00:05:08,830 because typescript is going to guide you along the way. 68 00:05:09,050 --> 00:05:09,310 All right. 69 00:05:09,320 --> 00:05:11,910 So now there is one less very quick thing I want to take care of. 70 00:05:11,960 --> 00:05:16,470 This is a very small oversight inside of customer. 71 00:05:16,500 --> 00:05:19,680 We are extending the air base class as a reminder. 72 00:05:19,710 --> 00:05:24,480 Normally when we create a new air or throw in air we'd write out something like new air then we put 73 00:05:24,480 --> 00:05:26,500 the reason for the air inside of here. 74 00:05:26,550 --> 00:05:32,570 So generally whenever we create an air instance we pass in a string describing exactly what just happened. 75 00:05:32,820 --> 00:05:38,550 As we've discussed a billion times now we didn't really want to rely upon that string too much for trying 76 00:05:38,550 --> 00:05:42,290 to communicate any information that eventually will get sent back out to the user. 77 00:05:42,300 --> 00:05:48,060 However these error messages or whatever string we put inside there will still be printed out inside 78 00:05:48,060 --> 00:05:49,350 of our server logs. 79 00:05:49,500 --> 00:05:54,180 And so it kind of would be nice if something goes wrong inside of application to still have some kind 80 00:05:54,180 --> 00:06:01,180 of actual string something and says hey for logging purposes here's what just happened so to make sure 81 00:06:01,180 --> 00:06:05,930 that we still have that behavior or to essentially have something equivalent to it. 82 00:06:05,930 --> 00:06:10,870 This right here we need to make sure that whenever we create an instance of something that is an error 83 00:06:11,050 --> 00:06:16,690 we pass in the error message or this string into that super function right there when we call super 84 00:06:16,690 --> 00:06:17,130 right there. 85 00:06:17,140 --> 00:06:19,190 That's equivalent to calling new air. 86 00:06:19,210 --> 00:06:20,460 More or less. 87 00:06:20,700 --> 00:06:26,580 So I got to say in addition to being a customer in addition to having a status code and serialized errors 88 00:06:26,580 --> 00:06:33,560 and all that stuff you also have to make sure that you provide a message that is a string. 89 00:06:33,690 --> 00:06:38,960 We'll just take that message and pass it on through to the air. 90 00:06:38,990 --> 00:06:43,960 So now when I saved that we're going to get an error from our database connection error and request 91 00:06:43,960 --> 00:06:49,020 validation as well because they want to see a string or a default message being passed in. 92 00:06:49,030 --> 00:06:52,630 So again this is just for logging purposes so we can put something inside of here that really just makes 93 00:06:52,630 --> 00:06:53,770 sense to you and I. 94 00:06:53,830 --> 00:07:00,010 So we could see something inside of here like air connecting to D.B. again really just duplicating the 95 00:07:00,010 --> 00:07:05,700 reason right there and then same thing for request validation we could put in something like invalid 96 00:07:05,710 --> 00:07:08,660 request parameters. 97 00:07:08,940 --> 00:07:11,490 Again this is really just for logging purposes. 98 00:07:11,520 --> 00:07:15,080 This is never gonna be sent out to any of our users or anything like that. 99 00:07:16,170 --> 00:07:16,440 All right. 100 00:07:16,450 --> 00:07:21,070 Very last thing I swear I know said that so many times by really promise at this time last thing we're 101 00:07:21,070 --> 00:07:26,350 going to do we're going to reap the benefits of all this air stuff inside of our air handler middleware. 102 00:07:26,530 --> 00:07:31,390 Now rather than writing out these separate if statements and watching for every possible custom air 103 00:07:31,390 --> 00:07:38,620 class any customer we build should be technically an instance of the custom air class so we can change 104 00:07:38,710 --> 00:07:43,500 these if statements and condense them down to just one single check at the very top. 105 00:07:43,500 --> 00:07:49,720 I'm going to delete those two import statements or the very specific customers we put together and I 106 00:07:49,720 --> 00:07:55,630 will replace it with customer from up one directory heirs custom air. 107 00:07:55,990 --> 00:08:00,190 And now we can go down to just one if statement so going to delete the second one. 108 00:08:01,210 --> 00:08:07,510 And we can update the instance of check to be custom air instead and that's it. 109 00:08:08,550 --> 00:08:17,330 So now if we throw any air from a request handler that is extending customer our area handling Middleware 110 00:08:17,360 --> 00:08:18,710 is going to handle it appropriately. 111 00:08:18,710 --> 00:08:22,840 It's going to take the status code off the custom error instance. 112 00:08:23,120 --> 00:08:27,830 It's going to call serialize errors and this is going to 100 percent guarantee as best as we possibly 113 00:08:27,830 --> 00:08:33,860 can that whenever we send a response back from any root handler in any of our services we're always 114 00:08:33,860 --> 00:08:39,890 going to have a very consistent structure going back to something that looks like this right here but 115 00:08:39,890 --> 00:08:43,960 of course we did end up with message and built like so. 116 00:08:43,970 --> 00:08:47,420 So we'll always have guarantees as best we can. 117 00:08:47,420 --> 00:08:51,940 Once again that we will end up with this structure. 118 00:08:52,010 --> 00:08:52,340 All right. 119 00:08:52,340 --> 00:08:58,170 Once again I know this area handling stuff has been really nasty but we're finally done with it. 120 00:08:58,250 --> 00:09:02,180 One of the reasons that we spent so much time on this error handling stuff is that it turns out that 121 00:09:02,180 --> 00:09:06,820 there's actually a couple other locations or a couple other things you have to do in all these micros 122 00:09:06,820 --> 00:09:11,140 services that's going to be relatively similar in nature to what we just did. 123 00:09:11,180 --> 00:09:16,520 So we have tried to essentially condense down a ton of functionality make it reusable in nature and 124 00:09:16,520 --> 00:09:21,440 we also try to build up some type guarantees through the use of this abstract class right here. 125 00:09:22,130 --> 00:09:26,150 There are going to be some other scenarios some other things we're going to go through where we want 126 00:09:26,150 --> 00:09:31,090 to guarantee functionality again as best we can across all of our different services. 127 00:09:31,190 --> 00:09:35,390 Most specifically this really comes down to a lot of that event handling stuff that we did manually 128 00:09:35,390 --> 00:09:40,130 back on our last project so we're gonna go through a somewhat similar process when we start to build 129 00:09:40,130 --> 00:09:42,570 out all the event handling stuff this time around. 130 00:09:42,590 --> 00:09:46,460 And again that's why I wanted to go through this kind of deep dive on the air handling stuff make sure 131 00:09:46,460 --> 00:09:51,920 it was clear about why we agreed the abstract classes why we were extending a base class why we wanted 132 00:09:51,920 --> 00:09:58,200 to guarantee the structure of data coming to the middleware and all this good stuff well before we stop 133 00:09:58,290 --> 00:10:00,840 we probably should do just a very quick test here why not. 134 00:10:01,020 --> 00:10:08,100 I can go over to post man I'm going to try to sign up with an invalid e-mail get looks good and I'll 135 00:10:08,100 --> 00:10:15,460 put in a valid e-mail and I get air connecting to database awesome. 136 00:10:15,640 --> 00:10:16,310 This looks good. 137 00:10:16,330 --> 00:10:18,980 Let's take a pause right here and continue in just a minute.