So I assume the real use for this feature is inheritance? If you create a new class that extends Library with a different list of books, will it re-run the same code for the new list? If so, that would be useful.
Also, if these blocks can generally be used to initialised classes, one use-case I'd have is to use this on a wrapper around HTMLElement, to have derived classes automatically register themselves as custom elements.
Currently you need to create a class extending my wrapper, then call a static initialise method to set things up, which I don't quite like.
If you create a new class that extends Library with a different list of books, will it re-run the same code for the new list? If so, that would be useful.
No, it has nothing to do with inheritance. Derived classes may benefit from the results of static initialization but each class has it's own initialization and statics have to be called by class name anyway so there is no static "override" mechanism.
Currently you need to create a class extending my wrapper, then call a static initialise method to set things up, which I don't quite like.
Perhaps I'm misunderstanding but why not just register when the module (script) is loaded?
In my view the existence of modules diminishes the need for classes - they tend to be better isolated and more flexible.
Perhaps I'm misunderstanding but why not just register when the module (script) is loaded?
You are mostly correct, of course, but this is still needless boilerplate. My setup is HTMLElement -> BetterHTMLElement -> MyComponent and I would like BetterHTMLElement to hold all the boilerplate, but currently, after defining class MyComponent extends BetterHTMLElement I will still have to call MyComponent.initialise() for some of the magic to happen, which I don't like. In a perfect world, JS would have hooks for extending classes like ruby does.
No, it has nothing to do with inheritance.
Then this is just one more utterly pointless feature added to the language for bloat and giggles.
For example, if you need to evaluate statements during initialization (such as try..catch), or set two fields from a single value, you have to perform that logic outside of the class definition.
Personally in JavaScript I've always viewed class itself as bloat (composition over inheritance and all that) - but with the introduction of custom elements its existence has been pretty much cemented into JS for all eternity.
When I do feel compelled to use classes they're usually just wrappers using core module functionality expressed in terms of plain objects and functions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My first thought is: Why not initialise the variable directly?
So I assume the real use for this feature is inheritance? If you create a new class that extends
Librarywith a different list of books, will it re-run the same code for the new list? If so, that would be useful.Also, if these blocks can generally be used to initialised classes, one use-case I'd have is to use this on a wrapper around
HTMLElement, to have derived classes automatically register themselves as custom elements.Currently you need to create a class extending my wrapper, then call a static
initialisemethod to set things up, which I don't quite like.ECMAScript class static initialization blocks
No, it has nothing to do with inheritance. Derived classes may benefit from the results of static initialization but each class has it's own initialization and statics have to be called by class name anyway so there is no static "override" mechanism.
Perhaps I'm misunderstanding but why not just register when the module (script) is loaded?
In my view the existence of modules diminishes the need for classes - they tend to be better isolated and more flexible.
You are mostly correct, of course, but this is still needless boilerplate. My setup is
HTMLElement -> BetterHTMLElement -> MyComponentand I would likeBetterHTMLElementto hold all the boilerplate, but currently, after definingclass MyComponent extends BetterHTMLElementI will still have to callMyComponent.initialise()for some of the magic to happen, which I don't like. In a perfect world, JS would have hooks for extending classes like ruby does.Then this is just one more utterly pointless feature added to the language for bloat and giggles.
Motivations
Personally in JavaScript I've always viewed
classitself as bloat (composition over inheritance and all that) - but with the introduction of custom elements its existence has been pretty much cemented into JS for all eternity.When I do feel compelled to use classes they're usually just wrappers using core module functionality expressed in terms of plain objects and functions.