Hacker News Reader

Comment by qsort | Hacker News Reader

Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about?

There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.

View on HN

> Doesn't it introduce a weird (stateful!) computation that's hard to reason about?

Yes and no. For example, maybe you want to initialise a temporary directory on the filesystem for writing files to, for some caching mechanism. The pointer to the cache directory (maybe a const x = {}) can exist anywhere, but spinning up the directory itself in the static class block ensures that it's set up once and only once for all instances of the class. So, any instances get to reuse the directory without worrying about checking for initialisation first.

Just another tool in the toolbox, best evaluated on a case-by-case basis

That's a pretty terrible example. No way do you want temporary directories to be created just by loading a class. That violates all sorts of best practices.

There's a better example here: https://v8.dev/features/class-static-initializer-blocks

You could also use it for initialising generated constants.

What’s the difference from declaring the entropy pool in the example outside the class, in the module scope? Still private, still a single shared value.

I think just scope (same reason static class members exist).

Off the top of my head it's probably useful for implementing The Singleton Pattern, which reduces to one single instance of a class: https://en.wikipedia.org/wiki/Singleton_pattern

Singletons in JS/TS are done by creating and exporting an instance of a class:

  class MyClass {}
  export const myClassSingleton = new MyClass()

Static initialization blocks = "Constructors, for static class members/values"

Static blocks only run once, like the class declaration itself:

  class User {
    constructor(public name: string, public age: number) {}

    static {
      console.log("Hello from class User static block")
    }
  }

  const a = new User("a", 1)
  const b = new User("b", 2)

Is transpiled to:

  class User {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }
  }
  (() => {
    console.log("Hello from class User static block");
  })();
  const a = new User("a", 1);
  const b = new User("b", 2);

That's pretty close, but you need to add the protections around Object.keys(...) with guards in the getters and setters when using JS/TS. Sealing the entire class static should prevent the need and ability to edit that way.

Another perspective on static blocks is what they replace/help migrate away from. Static blocks are one of the last pieces of the puzzle holding some projects (or at least some particularly old legacy objects in those projects) from migrating to the new class syntax. For better or worse the classic Constructor Function pattern of building objects in JS was full of static initialization code (as it was an easy thing to do in that pattern). Static blocks bring back a way to do that in class syntax while adopting the better scoping rules of class syntax, helping more projects move away from Constructor Functions to class syntax.

Yeah, this makes a lot of sense. ES6 classes are restrictive if you look at them from a pre-ES6 perspective. Of course many of those restrictions are "right", but they are restrictions nonetheless.

I guess it's a good way to bring back that behavior with the added bonus of being useful by itself in some limited but legitimate cases (sibiling comment mentioned cache initialization, also a good point).

Here's a pattern I've been using for some time in ES6 JavaScript (on Node.js) :

   module.exports =  
   class MyClass
   { // ...

     static init ()
     { // ... do something, like create and 
       // cache a Singleton etc. 
       return this;
     }
   } . init();

The static method init() is executed only once when the class is created and exported. You could add some check to it that causes an error if it gets called more than once.

Do static blocks allow me to do something more?

Modifying class static private properties

It might be helpful if you have a "registry" of classes. The classes can self-register statically, rather than you having to add separate code which registers the just-declared class.

It seems like a minor convenience, but it might play well with inheritance or mixin classes?

You can use it to load or compute derivatives of environmental configuration once

Reply on news.ycombinator.com