Think of it like researching some basics of the language of a destination before you board a plane versus telling yourself you will look at a book during the plane ride. Realistically, you will be much more interested in wine and a nap on the plane – it’s probably too late at that point anyway, and there is a really good chance you will be glad you planned ahead at some point in your near future.
Concepts to keep in mind:
1. One thing to consider in JS prototypal inheritance, is that properties are shared and that this sharing may be unexpected to those who are used to classical inheritance. So, if you have a parent with an array property, you may be tempted to think that if you have two classes inheriting from that parent that they both each get an array to themselves. This isn’t the case, though. They share that array.
So, if you add something to that array from a second (or third, fourth, or twentieth) inherited object, then the first one (and all of the others) will now also have what you added to that property that is being referencing. Ultimately, this is a big part of how the prototype chain works, and it’s not a big deal, but don’t let yourself be surprised by this.
There are some common ways around this when you need different behavior including putting intended instance properties in a constructor or using an initialize function. Each of these has pros and cons such as the need to remember to call subclass.prototype.initialize in all subclasses if you go the initialize route.
This is true for reads, but writing to the object – either assigning a value to a property or deleting a property – does not go up the chain, but stays at the current object referenced by this. In long chains, going up the tree is something to keep in mind from a memory usage perspective. Also, keep in mind that you can check to see if a property belongs to the current object using the hasOwnProperty() or the in operator method.
And one more thing – the last stop is actually always Object.prototype from which all reference types inherit by default.
3. Keeping in mind the above two concepts, instances always get the latest inherited values no matter when they were changed. And, since methods are just another property, and since they only appear to by properties of an object but actually belong to the parent, you can add new ones at any time and dynamically change behavior.
5. Since everything is a chain lookup, properties are shadowed, not overridden, and access to the shadowed property on the parent prototype on the object is blocked. The first one found on the aforementioned chain lookup is the one used even if other properties of that name exist higher in the chain.
6. Overloading doesn’t technically exist. Instead of creating several methods with different signatures, you can have a master function. Since JS doesn’t type check arguments or require a certain number of arguments, you can work accordingly inside the method – processing from there or delegating to different methods.
Alright, hopefully this is a helpful start. It’s time to get excited about your flight.
— Adrienne Gessler, firstname.lastname@example.org