What (if any) is the plan for assigning to undeclared properties in ES6 classes

[sccolbert]

The following snippet is valid ES6, but does not compile due to the undeclared property thing. Since TypeScript is aiming to be a superset of ES6, how will this situation be approached?

class Thing {
    constructor() {
        this.thing = 12;
    }
}

[RyanCavanaugh]

Many things in ES5 are also errors in TypeScript, e.g. 'hello' * 'world', or var x = { n: 3 }; x.m = 4'. The code will still emit (it's syntactically OK) but you'll need to declare class members.

It's possible we could do some inference (e.g. a set of contiguous simple assignment expressions to this. act as if they are declarations) but I don't think anyone's written a proposal to that effect yet.

[CyrusNajmabadi]

@sccolbert The way to address this is to declare the property. You can do this like so:

class Thing {
  thing;
  constructor() {
    this.thing = 12;
  }
}

You can also optionally give this property a type and/or accessibility modifier like so:

class Thing {
  private thing: number;
  constructor() {
    this.thing = 12;
  }
}

[basarat]

Using undeclared members has the potential for errors (e.g misspelling). Admittedly this is more useful in constructors than member function bodies.

This can be eased with tooling though.

[nycdotnet]

@RyanCavanaugh I wrote up a proposal for this several months ago. #766

@sccolbert 's example could be implemented as the below with this proposal:

class Thing {
    constructor() {
        public this.thing = 12; //or private or protected
    }
}

[CyrusNajmabadi]

@nycdotnet I'm not sure why we'd need new syntax for this. This use case is already handled by the existing syntax we have.

[nycdotnet]

It's handled with existing syntax if you don't mind the type being any or having to manually write out and then maintain explicit type declarations that are separate from the instantiations.

The proposed syntax enables implicit strong typing and requires way less busy-work for the developer converting their existing (or in this case new since it's ES6) class to TypeScript, and less maintenance in the event of changes.

[sccolbert]

I was coming at this question from the angle of a new user gradually moving some existing ES6 project to TypeScript. When TypeScript claims (aims) to be a "superset of ES6", a new user would expect valid ES6 code to compile without error, just like this ES5 code compiles without error:

function Thing() {
   this.thing = 42;
}

However, I'm not trying to push for any change to the language here. I'm simply wanting clarification on the narrative for whether TypeScript will cleanly compile any ES6 code base, so that I can accurately relay that message to people who ask.

[basarat]

I'm simply wanting clarification on the narrative for whether TypeScript will cleanly compile any ES6 code base,

I've traditionally said "good ES5 code is valid (no error) TypeScript code". There is no valid ES6 conterpart for what we force on TypeScript class structure.

[basarat]

Duplicate of #766

[basarat]

This can be eased with tooling though.

As promised : https://github.com/TypeStrong/atom-typescript#quick-fix