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 inclass
syntax 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.prototype
object inherits fromParent.prototype
. That way,Child.prototype
inherits the prototypical properties (if any) and methods (much more common) thatParent.prototype
provides.The
Child
function inherits from theParent
function (yes, really). That way,Child
inherits any static featuresParent
defines.E.g.:
Example:
It depends on whether you mean the object on
N.prototype
or the actual prototype of theN
function.If you mean
N.prototype
:N
is a constructor function, butN.prototype
is the object that will be assigned as the prototype of instances ofN
created vianew N
.If you mean the actual prototype of
N
:N
is a constructor function, but its prototype is the class constructor that it derives from (orFunction.prototype
, if it's a base class).