TypeScript 5+ Fundamentals, v4

Param Properties & Overrides

TypeScript 5+ Fundamentals, v4

Check out a free preview of the full TypeScript 5+ Fundamentals, v4 course

The "Param Properties & Overrides" Lesson is part of the full, TypeScript 5+ Fundamentals, v4 course featured in this preview video. Here's what you'd learn in this lesson:

Mike explains that param properties allow for the creation of class fields and constructor parameters with the same names, reducing the noise in class definitions. The use of the "override" keyword in TypeScript to indicate that a method in a subclass is intended to override a method in the base class, helping with refactoring and catching misspellings, is also discussed.


Transcript from the "Param Properties & Overrides" Lesson

>> I promised you at the beginning that we would have a way to take that very wordy way of, you know having all of these different class fields, right? Remember we had like make model and year each written four times. The answer here is something called param properties and I'll show you a freestanding example because that the car class up top is getting a little big and cumbersome and complicated.

I haven't make property here and you have to imagine we can add model in near here but so, this is this is interesting, we have the word public here in an arguments list. Seems weird, you can't do this with functions, you can't do this with methods only with a constructor signature.

And what this is constructor signature for, is actually the easiest way for me to cover this is Let me go to the example and jump to the TypeScript playground here. And we can see the compiled output really quick. So here's public make, model, and year, here's the JavaScript, this.make = make, this.model = model, this.year = year.

What it's doing is it's creating class fields, make model and year of the correct types of identical names of these parameters here. And then it's doing the assignment of the constructor, ARGs to those class fields, right? So it's taking these and it's putting them in the respective fields, and of course it's also setting up the appropriate types on those fields.

So if we look back in here, we can do this.make and something's there and its value has been set. So this is the abbreviated syntax, we can go back up to the complicated example here. We could delete this, and we could just here, write public, we could this other format there.

There you go, that's our constructor, it does exactly what the old constructor did, just much more abbreviated syntax because this is such a common thing. And to have class fields and constructor parameters of the same names in that assignment, it's such a common thing that it's worth it to have some special syntax for it.

Just to reduce the noise in every kind of class that you might have. I see a question in the chat that I wanna address real quick, it's about this static block, which we dealt with a little while ago. So the question from Alexandria is you can't really use this class until the static block completes how would you ensure that new is not called before the block completes.

Honestly what I do is something like this. And then before invoking the constructor, I would check to see if the class is ready or I might wait for this to indicate that it's ready before I like booted my application and started calling any code. That might instantiate cars but you do need a piece of data there that that lets you have some signal as to whether the data is landed and whether this initialization has completed.

That is work you have to do there, only if you're doing async stuff in your static blocks. Sorry for the little tangent there, but I think that's worth looping back for. All right, keep going onward. Overrides, so this just recently landed in TypeScript, I think it's a TypeScript five feature here.

And I wanna first illustrate the need for this with an example, so if you remember we had a class car has a does it have a honk property? Yep, there's the honk property, and so if we go down, we have added an extra O in here, we've misspelled this method name.

And this is a truck, it's honking in all caps because it's truck and not much is helping us here, I think I have a just a spelling error, so this is TypeScript not helping us at all here. And, so if we do this, we instantiate this truck, we're gonna get the hunk method on the base class.

I got a hug for five seconds or something. So the problem here is this is very common, long method names, misspellings happen. The only thing that's even remotely catching this is a spell checker, and if I just had You know, a word here, a misspelling that happened to be a word, I'd have nothing warning me of this situation.

So TypeScript introduces a keyword here called override. Override is it is you expressing the intent, that this should override a base class method and thus a base class method must exist of the same name. And here we go, member cannot have an override modifier cuz it's not declared in the base class, did you mean honk?

If I delete this that works or should, sorry, I have to take in. Something like that. Is that what the problem was? I have to return beep, my bad. There, now it's happy. So override is great, it helps to helps like keep that linkage in place. The thing you'd want watch out for if you didn't have this, of course, is you're not really overriding the base method and so your custom code for your subclass is not being run it all.

There's another problem that this helps with, and that is if the base method's name has changed. So if we go up here we were like I really want honk there we should see. Yeah, we see an indication that all right, my subclasses are lighting up, that linkage, that refactoring is not complete and, it's gonna tell me that I need to take care of that.

Now, what happens if you're not super vigilant here? Well, sometimes you forget to put the override, I mean, it'd be easy to forget. Especially, let's say initially, there was no honk in car, and then it was added later. What we can do in our tsconfig is say noImplicitOverride, so I'm gonna add that to our notes.

Notes/tsconfig. Let's add noImplicitOverride: true, save. And what happens here is if we're lucky enough to not make the typo, we're prompted to add the override modifier, We're told, hook this up. It's useful, it's here to help you, it doesn't let you override unless you use this keyword, which is a great way to ensure that it's consistently used.

Now, you can always fat-finger a method name from the start, and it's tough to help you there like there's nothing TypeScript can do to understand whether that was your intent. Or maybe you did want a method with a different name, but once you get this right you can kind of establish it and this will catch a lot of the other places.

This is an amazing tool to help with refactoring to make refactoring a lot easier.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now