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

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

Mike reviews the proposed public and instance fields on classes in JavaScript.

Get Unlimited Access Now

Transcript from the "Public & Instance Fields" Lesson

[00:00:00]
>> Mike North: So under consideration right now. So when we say this is an ES 2018 stage 2 proposal here, that means that there's discussion going on about adding the ability to have public and instance fields on classes in regular JavaScript. The hope is, when I say ES2018 I'm not promising or indicating that it will be ready in the 2018 version of the draft.

[00:00:27] I should really probably just say stage 2 because there's no guarantee when it'll be finalized. But this is the proposed syntax here, where instance fields like this planet Earth I have as an instance property of person. That will be treated just like, that is the equivalent to putting a property on an instance in the constructor.

[00:00:51] So planet Earth here, that is being treated the same way we are treating name more or less. Think of it as in the constructor for each instance we are saying This.planet=earth. It is not the same as placing it on the prototype. Static fields do not require an instance and it’s the equivalent of just tacking something onto a constructor.

[00:01:10] So we should be able to do something like Person._counter and we’d be able to get this value. In this case, we can see that as we create new instances of person that counter is incremented and so that is state that is attached to the whole class as opposed to any given instance.

[00:01:33]
>> Mike North: I just want to draw a distinction between classes and prototypes. If we did this here, a very common snag that particularly people who come at JavaScript from other languages, and who sort of learn what they need to learn as they go along. They never really are forced to come to terms with what prototypes mean here.

[00:01:54] In this case, we have a property tags on the prototype of Person. The value of tags is an array and that is a mutable value JavaScript, right? Like we, we can alter that array and it is in fact shared across all instances. So here we can see we create two instances of Person and we go from.

[00:02:20] We push a tag into the array going through p1, person number 1. And we observe that person number 2 also like seems to have this tag on it. And the reason is, in this situation, we are sharing that same instance of an array tags across all persons that we create.

[00:02:38] It's one array they're all point to it. Because there's only one copy of this prototype in memory. It's sort of the fallback whenever we're asking for properties on an instance of person, and those instances don't have anything for us. We go to the prototype and we see what's there, right?

[00:02:55] And in this case that's mutable data, and so that's gonna create. This is unintuitive for a lot of developers. If you're coming to JavaScript from Java and you think that prototype is like a class you're gonna be surprised by this. I just wanna clarify that if we change that and now we have class person with tags like this, now this is in the constructor and that tags value, that array will be cleared on a per instance basis, and in fact, we will not see that leaking across incidences anymore.

[00:03:25] So when I say the classes have a way of sending down some of the sharp edges and corners around prototypes, that's what I'm referring to here, right? We don't really have, unless we use the starter keyword, we kinda have to opine to shared multiple state across instances. And sort of that being the default.