proposal-decorators
proposal-decorators copied to clipboard
tc39
Decorators for ES6 classes
**Please post your use cases for decorators as an issue comment, and we'll see if we can document them in the cookbook** Let's write a how-to guide about how to...
Member decorators (method, accessor, field, etc.) in the current proposal do not have access to the class constructor or prototype, and thus have no access to the name of the...
See https://github.com/tc39/proposal-decorators-previous/issues/45 Leaving for v2.
Right now, composing decorators is much too cumbersome. You have to write conditional branches inside of a new function to handle all the `kind`s of decorators, and often you repeat...
This repo has a lot of really [great & valuable extensions](https://github.com/tc39/proposal-decorators/blob/master/EXTENSIONS.md) that could limit boilerplate in a lot of userland reactive libraries (specifically / let & const decorators). Is there...
Hi, since this proposal has gained some exciting momentum recently, I would like to give a perspective from a potential user of decorators that you probably haven't heard from yet:...
The current syntax ``` DecoratorMemberExpression[Yield, Await] : IdentifierReference[?Yield, ?Await] DecoratorMemberExpression[?Yield, ?Await] . IdentifierName DecoratorMemberExpression[?Yield, ?Await] . PrivateIdentifier ( Expression[+In, ?Yield, ?Await] ) ``` disallows `super.dec` as a decorator member expression,...
