Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[BUG] not @computed decorators work in file.js but fail in file.ts #162
yarn list v0.27.5
how to reproduce ?
=> you should get the followin JS error
ember.debug.js:19840 TypeError: Cannot read property 'enumerable' of undefined at handleDescriptor (decorator-wrappers.js:15) at decorator-wrappers.js:43 at __decorate (component.js:68) at Module.callback (component.js:100) at Module.exports (loader.js:106) at requireModule (loader.js:27) at Class._extractDefaultExport (index.js:387) at Class.resolveOther (index.js:108) at Class.superWrapper [as resolveOther] (ember.debug.js:42856) at Class.resolve (ember.debug.js:7200)
=> you should get no JS error and the following text rendered in the browser
The slack archive has disappeared here so going to report my findings for posterity:
According to the decorators/class fields specs, class fields which are decorated will not actually have a descriptor on the class before the decorator is run. This makes sense as class fields are not prototype state but instance state - they aren't assigned until the constructor of the instance runs.
Babel is actually in the wrong here, and all of our decorators assume that a descriptor will exist and we can use its properties because that's how it currently transpiles it. Typescript has it right, we'll have to make decorators for class fields which don't have descriptors.
referenced this issue
Sep 13, 2017
That seems correct @bartocc, ran into this issue this morning with TypeScript. For class fields, TypeScript will pass the descriptor argument:
The problem here is that
Actually looking at more recent versions of the spec, it looks like both of them may need an update. It's hard to say exactly (spec language being notoriously difficult to read) but these are the two relevant sections:
If I'm reading this correctly (and that's a big if) it looks like the decorator API is going to change to return quite a bit more information, and the signature of decorators will change to
In the end the spec is in flux so I don't think we can say for sure who is right here. For some of the decorators we have we can definitely account for there being no way to access the initializer, but for others we may need the value (and be dead in the water). Either way, we should fix the decorators for now and wait for the next revision of TS and Babel to try to sort it out.
Update on this:
The behavior differences between Typescript decorators and the Babel decorators that
Babel is currently implementing the Stage 2 decorators spec, so we'll have to update either way once that lands. The TS design meeting notes indicate that they won't be updating anything until decorators reach stage 3, per their policy (only implement stage 3 features), so it could be a while