In JS, there's no way to assert that a property is definitely assigned

[DanielRosenwasser]

Keywords: JSDoc, Salsa, JavaScript, definite, initialization, initialized, assigned, assertion

class ElementWrapper {
  constructor() {
    this.init();
  }

  init() {
    this.element = document.createElement('div');
  }

  getElementStyle() {
    this.element.style // error: element is possibly undefined
  }
}

We need a way to convince TypeScript in strictNullChecks that this.element is initialized in getElementStyle. Basically a definite initialization assertion.

Related is #23405 which tracks non-null assertions on the expression level.

[mhegazy]

@DanielRosenwasser had an idea of an /** @delayinitialized */ on the declaration..

We can also add a tag on init like /** @initializer */ to treat it like a constructor for purposes of definite assignment detection.

[mqudsi]

Wouldn't simply following the constructor call chain be simpler?

[beauxq]

Since someone mentioned following the constructor call chain:
#30462

[mqudsi]

Thanks for the heads-up. I'm always surprised when I remember this isn't the case.

[clshortfuse]

The only way I can define is in Subclass.prototype after the declaration:

class Superclass extends HTMLElement {
  static {
    console.log(1, 'Super Static Init')
  }

  static superStaticField = console.log(2, 'Super Static Field')

  static observedAttributes = ['foo'];

  constructor() {
    console.log(8, 'Superclass constructor: pre-super()');
    super();
    this.superConstructorVar = console.log(10, 'Superclass constructor: post-super()');
  }

  superInstanceField = console.log(9, 'Superclass Instance Field');

}

Superclass.prototype.superInstanceProp = console.log(3, 'Super post-declaration' );

class Subclass extends Superclass {
  static {
    console.log(4, 'Sub Static Init');
    
    this.prototype.a = 1; // ts-error
    Subclass.prototype.b = 2 // ts-error
  }

  static subStaticField = console.log(5, 'Sub Static Field');

  static get observedAttributes() {
    console.log(6.5, 'HTMLElement reads observedAttributes from subclass');
    return ['foo'];
  }

  attributeChangedCallback() {
    console.log(13, 'Attributes observed');
  }

  constructor() {
    console.log(7, 'Subclass constructor: pre-super()')
    super();
    this.subConstructorVar = console.log(12, 'Subclass constructor: post-super()');
  }

  subclassInstanceField = console.log(11, 'Subclass Instance Field');
}

Subclass.prototype.subInstanceProp = console.log(6, 'Sub post-declaration');


customElements.define('x-sub', Subclass);
console.log('Element added to registry');
const el = document.createElement('x-sub');
console.log('Element created');
el.setAttribute('foo', 'bar');
console.log('Attribute added');

This yields:

1 'Super Static Init'
2 'Super Static Field'
3 'Super post-declaration'
4 'Sub Static Init'
5 'Sub Static Field'
6 'Sub post-declaration'
6.5 'HTMLElement reads observedAttributes from subclass'
Element added to registry
7 'Subclass constructor: pre-super()'
8 'Superclass constructor: pre-super()'
9 'Superclass Instance Field'
10 'Superclass constructor: post-super()'
11 'Subclass Instance Field'
12 'Subclass constructor: post-super()'
Element created
13 'Attributes observed'
Attribute added

I have to use prototype because constructor() and instance class fields are too late. (I would like to append to the shadowroot based on class properties). I've resolved to using post-declaration at the end of the file, but defining properties at the end of the class is awkward. I would rather use the Class static initialization blocks, but Typescript will not define the type there. That's because it rewrites that code as:

_a = Subclass;
(() => {
    console.log(4, 'Sub Static Init');
    _a.prototype.a = 1;
    Subclass.prototype.b = 2;
})();

I'm not sure why the IIFE is needed, but if it can reworked, I think it would be fine.

Playground Link

[ilogico]

Following the program flow is not always possible.
Consider this:

class R {
  accept;
  constructor() {
    new Promise(accept => this.accept = accept);
  }
}

[beauxq]

Following the program flow is not always possible. Consider this:

class R {
  accept;
  constructor() {
    new Promise(accept => this.accept = accept);
  }
}

It is possible to follow all of the constructor's program flow in that example. And accept is not initialized before the end of that constructor. That is not a relevant example.

[ilogico]

@beauxq you're wrong on two points.
It's not possible to follow the program flow because it's impossible to know if the Promise constructor will run the function before it returns, which it does, making you wrong on the second point: accept is initialized before the end of the constructor.
It's fine to be wrong and it's ok to arrogant. Being arrogant and wrong is just hilarious.

[ilogico]

When I say it's impossible to know if the Promise constructor runs the executor before returning I mean from the type system's point of view.
We know, of course, it does.

[beauxq]

I see.
I don't see why you think it's impossible to know if the Promise constructor will run the function before it returns.

[ilogico]

Because the type system has no way of expressing that.

[beauxq]

That's just an assertion of what I'm saying I don't see.