TypeScript: preset class properties to undefined

• “re-typing” a class field in a derived class is easier.\

For type-only information something like this could work:

class Foo {
  public x: string; // initialized to undefined
  declare public y: string; // type-only
}

(Public) class fields are enabled by default in Chrome 72 with the initializer semantics outlined above. This part of the spec is extremely unlikely to change. Current topics of debate are just how private fields should work AFAICT.

Can we please revisit and get a decision here? While the Babel transform is not officially supported, they would want to wait for a decision by the TypeScript team before implementing any fixes: https://github.com/babel/babel/issues/9105

The major arguments for keeping the current semantics to me are:

• no breakage
• “re-typing” a class field in a derived class is easier.\

In favor of switching:

• spec compliancy
• less cognitive load for JS developers migrating to TS

Any input would be much appreciated ☺️❤️

@IgorSzymanski this continual moving of the goalposts isn’t indicative of a good-faith conversation. If you don’t think it’s important to you, that’s fine, but no one is required to justify spec compliance as a valid goal

Any news on this? This kind of behavior is as important as common and standard. Would be great to fix it.

While this is the original/current behavior, the current ES proposal seems to actually imply that a property will indeed be defined & set to undefined even without an initializer.

https://tc39.github.io/proposal-class-public-fields/#initialize-public-static-fields

You need to explicitly initialise them as undefined to have the effect you want.

Input

class ImplicitlyUndefinedProperties {
	public foo: string;
	public bar: string;
}

class ExplicitlyUndefinedProperties {
	public foo: string = undefined;
	public bar: string = undefined;
}

Output

var ImplicitlyUndefinedProperties = (function () {
    function ImplicitlyUndefinedProperties() {
    }
    return ImplicitlyUndefinedProperties;
}());
var ExplicitlyUndefinedProperties = (function () {
    function ExplicitlyUndefinedProperties() {
        this.foo = undefined;
        this.bar = undefined;
    }
    return ExplicitlyUndefinedProperties;
}());

Therefore I think that this is not an issue but is intended behaviour.

Not yet, but we should probably change that.

Could I propose that only fields whose types include undefined be initialized as such? It seems to me that initial example, where the fields were just removed, ought to be disallowed – if the value is non-optional but also never set in a constructor, then that should just be a type error.

So this should be fine:

class Foo {
  public x?: string; // initialized to undefined
}

and this should be an error:

class Foo {
  public x: string; // TypeError -- x can't be undefined
}

This is now the behavior under --useDefineForClassFields

Then initialise your properties explicitly. This is a breaking change, it breaks the logic behind explicit property initialisation and, once again, I do not see any use case where it should matter. In OOP, you shouldn’t really ask for properties of a class instance, because it breaks its encapsulation. In FP, you wouldn’t even use a class for this, and therefore you would have to initialise the property on your own. This change is nothing but an attempt to encourage a bad programming style.

I also do not see, why you would want to run a class instance against Object.assign or object spread. Mind to elaborate?

Give me a valid example of why the lack of implicit property initialisation in a class instance is an issue.

What is the use case for this one? undefined is the spiritual equivalent of the lack of a property, thus:

type LolRly = { prop?: bool }
const A: LolRly = {}
const B: LolRly = { prop: undefined }
console.log(typeof A.prop) // undefined
console.log(typeof B.prop) // undefined
console.log(JSON.stringify(A)) // {}
console.log(JSON.stringify(B)) // {}

If you want to do some dirty, 5-minute life hacks with iterating over an object properties (and I can smell from a mile, that it’s exactly what you’re trying to do), then null is for that to represent an existing property with en empty (NULLABLE) value. Even if JS/TS can produce and allows the existence of an object with a property initialised with undefined value, it should be treated as if it wasn’t there in the first place.

You’re partly correct, but there are ways that people with strictNullChecks but not strict or strictPropertyInitialization can be broken by this, precisely it’s breaking in terms of compiler output, not only in terms of type-checking. If you have a way that a property is known to be initialized outside the constructor (e.g. component arguments, which may be checked via debug assertions or the like), the behavior can change with this. We saw these breaking changes in practice across many applications when we changed to using TS only for type checking and Babel (which is spec compliant) for actual compilation in Ember apps and addons.

That said, deferring it to strictPropertyInitialization or strict doesn’t seem unreasonable, since it’s impossible for this not to be a breaking change in some way. (It should, however, be code-mod-able given a satisfactory design.)

Looks like there’s already https://github.com/microsoft/TypeScript/issues/39311.

Separate issue please. Thanks!

Anything using object spread or Object.assign will care about it being a present, own property, even if set to undefined. undefined is not simply “not defined”, in JS, there exists “absent”, “present but set to undefined”, and “present but set to non-undefined”.

@ljharb I ask again for the use case. Also, if you do not initialise and optional property, why do you expect it to be initialised with undefined? If you do not initialise an optional property, the expected behaviour is it’s not there, uninitialised shouldn’t be initialised, and that’s exactly what happens.

Also, the OP example is horrible.

If you define a property as non-optional number, it should be nothing else, but a number. No part of the code says it can be undefined.

@kutomer I think what @nicolo-ribaudo wanted to express is that the declare keyword could be used as new syntax, i.e. it does not work yet and would be a breaking change to TypeScript. 🙂

@nicolo-ribaudo not sure how it’s possible, tried it on ts playground and got declare' modifier cannot appear on a class element.