Please be informed that you are just spamming around.
And your solution is not good at all. You cannot super() in the constructor and you cannot extends the class. And your constructor is not a constructor, which is harmful.
Developer advocate, full-stack engineer, startup co-founder & CTO, bringing 15 years of experience in Silicon Valley, including at Google and Yahoo!. Public speaker.
Location
🌐
Education
UC Santa Cruz Extension
Work
Developer Advocate at Weaviate, the open-source semantic search engine
Did you mean that more precisely, you can call super in the constructor; you can't await super() in derived class constructors, but you can extend the class if you don't need to overload the constructor? I've documented this downside in the SO answer.
Can you expand on how the constructor is not a constructor?
Pedantically, I am on the camp that constructors should never return anything at all. That's just an unexpected quirk of JavaScript that even tsserver trips up on.
Semantically, constructors initialize fields, not return values. Thus, returning a Promise from a constructor is not only awkward, but also unexpected because it returns something aside from the intended class instance (i.e., Promise<Animal> vs. Animal itself).
A static async factory method makes this distinction well: do the async work ahead of time and then invoke the constructor with the now-resolved field initializers.
Please be informed that you are just spamming around.
And your solution is not good at all. You cannot
super()in the constructor and you cannotextendsthe class. And your constructor is not a constructor, which is harmful.Did you mean that more precisely, you can call
superin the constructor; you can'tawait super()in derived class constructors, but you can extend the class if you don't need to overload the constructor? I've documented this downside in the SO answer.Can you expand on how the constructor is not a constructor?
A constructor should anyway return the constructed object itself, instead of a promise resolving to the said object, unless the object is the promise.
we are discussing creating objects asyncronously, in that case the constructor HAS to return a promise.
Pedantically, I am on the camp that constructors should never return anything at all. That's just an unexpected quirk of JavaScript that even
tsservertrips up on.Semantically, constructors initialize fields, not return values. Thus, returning a
Promisefrom a constructor is not only awkward, but also unexpected because it returns something aside from the intendedclassinstance (i.e.,Promise<Animal>vs.Animalitself).A static async factory method makes this distinction well: do the
asyncwork ahead of time and then invoke theconstructorwith the now-resolved field initializers.Exactly. Constructors are even called
__init__in Python (which is very close to JS regarding OOP design).