Before marking my question as a duplicate of "What is the prototype is JavaScript?" please note that this question is focused on the prototypes of the ES6 classes. Although the prototype chain conception is involved, the implementations of the inheritance mechanism at ES5- are off-topic.
Unfortunately, the general explanation about inheritance and the prototype chain does not give a clear answer to my question. Contrariwise, it creates new questions.
I did not care about prototypes of the classes until not tried to create the decorator (on the non-static class property). In the case of non-static class property fields, the first parameter of the decorator function is the prototype of the target class.
From the viewpoint of general explanation, the prototype of the target class is completely useless (at least I don't understand what to do with it even know that this prototype is related to some class) - what is seems to be valuable is the class itself.
export function VueReactiveField(
classPrototype: unknown, // What it this? What we can do with it?
fieldName: string
): void {
}
Moreover, the prototype has doubled the complexity. If this equation we have for variables now:
- Target class (everything is clear)
- The instance of the target class (everything is clear)
- The prototype of the target class (I don't understand its essence)
- The prototype of an instance of the target class (I don't understand its essence)
Note that
class, primarily, is just syntax for building constructor functions and the objects they assign as prototypes to instances. It's not a different kind of prototypical inheritance from constructor functions. It's a different way of writing those. (Plus there are now some features inclasssyntax that are not available if you write constructor functions the old way, such as private fields.) I cover that part of things in more detail in this answer.Usually when someone says "the prototype of class X," they mean the object on the property
X.prototype. That phrase is arguably not quite correct (or at least slightly imprecise), but it's common.Let's say you have:
That sets up two inheritance relationships:
The
Child.prototypeobject inherits fromParent.prototype. That way,Child.prototypeinherits the prototypical properties (if any) and methods (much more common) thatParent.prototypeprovides.The
Childfunction inherits from theParentfunction (yes, really). That way,Childinherits any static featuresParentdefines.E.g.:
Example:
It depends on whether you mean the object on
N.prototypeor the actual prototype of theNfunction.If you mean
N.prototype:Nis a constructor function, butN.prototypeis the object that will be assigned as the prototype of instances ofNcreated vianew N.If you mean the actual prototype of
N:Nis a constructor function, but its prototype is the class constructor that it derives from (orFunction.prototype, if it's a base class).