TypeScript 3 Fundamentals, v2

TypeScript 3 Fundamentals, v2 Access Modifiers & Initialization

Topics:

This course has been updated! We now recommend you take the TypeScript Fundamentals, v3 course.

Check out a free preview of the full TypeScript 3 Fundamentals, v2 course:
The "Access Modifiers & Initialization" Lesson is part of the full, TypeScript 3 Fundamentals, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Mike demonstrates how to use access modifier keywords to make the class initialization more succint.

Get Unlimited Access Now

Transcript from the "Access Modifiers & Initialization" Lesson

[00:00:00]
>> Mike North: We can see right away that this is a lot, this is verbose. We have to specify email and name. Those words are here three times, right? Once to define the type, once in the constructor signature and then as we pass from function arguments onto the instance. So TypeScript has a shortcut for this called Parameter Properties.

[00:00:22] And we're gonna look at that. But at the same time, we have to introduce these access modifier keywords. So you'll see these as being one of three choices, public, which is what you're used to, right? The only thing we have in JavaScript is public, and public with an underscore, which means shame on you for using that, but it's still public.

[00:00:44] Protected allows the instance, and any instance of a subclass, to see it. In private, means only that type can see it, only that class. Even a subclass won't be able to see a private method or private field. So, here is an example of these parameter properties. And unfortunately, the auto formatting kinda makes things less than ideal.

[00:01:10] So, the difference here from our previous example, obviously, there are a lot of things that are not present. But through adding an access modifier keyword before our constructor's arguments, we can create the equivalent setup to what we had before. In fact, I have even added a little something here, and that is the default value for the second field.

[00:01:34] So this means I take an argument in my constructor and a parameter like a field of the same name should exist on the instance. And when you receive it in the constructor, you should place it on the instance. And I'm gonna convince you of this by taking this exact same example.

[00:01:54] I'm just gonna remove the interface. And I'm gonna put it into the TypeScript Playground so we can see the JavaSscript that it compiles to.
>> Mike North: And get rid of the interface. So, on the right side, I know we're getting cut off here but we can see that if the email is, this is undefined, void 0 is undefined, if the email is undefined, initialize it with the default value.

[00:02:23] And then we will receive name as a function argument, we put it on the instance, same with email. And then this is the comment that was actually in the body of our constructor. So you can see anything in your constructor that you do custom, would happen after all of this mapping from parameters to fields has taken place.

[00:02:45] This is a really nice convenience because it allows us to do this common thing where we want to pass some stuff into a constructor, get the fields, it makes it a lot less verbose. Note that if we were to make this protected, which means the outside world when interacting with an instance of ParamPropContract, it wouldn't be able to see this field.

[00:03:15] So, we still can receive it as an argument, but you're not going to be able to access it from the outside.
>> Mike North: Just passing in some nonsense fields here, nonsense values rather. Down here you can see we only have access to name whereas before, we have access to both.

[00:03:38] So that's the difference in making it public or protected. And you'll note that another consequence of me making it protected was I get an error up here saying the class incorrectly implements the interface HasEmail. Can anyone make a guess as to why this error is happening? Clearly, the field is there, but why might TypeScript be objecting?

[00:04:07]
>> Speaker 1: Email's not visible.
>> Mike North: Email's not visible. You expect the instance of this class to be a HasEmail, meaning you can access name and you can access email. That's what it means to be a HasEmail. So you're not really conforming to an interface unless the things that allow you to conform to it are public and visible from the outside.

[00:04:34]
>> Mike North: And now the error goes away.
>> Mike North: So class fields can have initializers. If you want a ParamProp initializer, just do the same thing you would do for function arguments, cuz it is a function argument, that's kind of where it lives, right? So that's the default value for the email field.

[00:04:55] But if you have properties that are not things that you take in as arguments to a constructor, in this case, age, which you can see up at the top, you can just do the same thing you would do in JavaScript. This effectively is a default value. If it is not in some way set like within the constructor here.

[00:05:18] So if in here I were to do like age = 35, now like this will never come into play. It is only initialized with that if it has not yet been initialized up until that point. Where do we see evidence of that? It's basically gonna turn into this right here.

[00:05:35] If it's undefined, initialize it.
>> Mike North: Did you have a question?
>> Speaker 2: Yeah, does it infer the type, if you give it a default?
>> Mike North: Yes, because it's a, kinda same rules as a variable, you're giving it its initial value, and so it will do the best it can to make a reasonable guess of the type.

[00:05:57] Now the one thing you'd want to be careful of is if this could be a string or could be a number and you initialize it to a number, you're going to have to specific that you'll deliberately widen the type to include the possibility of a string. So it will make its usual guess and rightly so.

[00:06:17] I can take that away, and it'll still be number.
>> Mike North: There's one other thing that kind of fits into access modifier keywords, although it's not really about access in terms of visibility. You could also do readonly. And that, from a type checking perspective, will yell at you for attempted sites where you are trying to write to this value.

[00:06:43] Don't fool yourself, through, because there may be JavaScript consumers of this library. And this does nothing at all in terms of actually preventing rights to this value. It is just like a renting thing for people using type information. So, I'll use this once in while but just be advised that not everyone uses type information.

[00:07:05] And this is just making a check, right?