preset class properties to undefined

[Jordan-Hall]

TypeScript Version: 2.1.1

Code

class PartialPolicySearchIten {
	public displayValue: string;
	public oriNumber: string;
	public parentName: string;
	public sysNumber: string;
	public systemCode: number;
	public systemName: string;
}

Expected behavior:

class PartialPolicySearchIten {
       constructor() {
        this.displayValue = undefined;
	this.oriNumber = undefined;
	this.parentName = undefined;
	this.sysNumber = undefined;
	this.systemCode = undefined;
	this. systemName = undefined;
       }
}

Actual behavior:
class PartialPolicySearchIten { }

The problem comes when using Reflection it can't find the properties. I would expected that the properties exists as i'm redefining them. Otherwise their very little point is declaring properties of a class.

[Jameskmonger]

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.

[DanielRosenwasser]

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

[RyanCavanaugh]

The proposal is now Stage 3 with this behavior. We need to discuss whether or not to take a break for this

[buschtoens]

(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: babel/babel#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 ☺️❤️

[nicolo-ribaudo]

• "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
}