State of Decorators

# Matthew Robb (a year ago)

Hello all!

Today it struck me that the usefulness and prevalence of Decorators in my React applications has been actively climbing and this feels to be at odds with the rate of progression within the committee. To me it is quickly rising as the most influential feature to the way I write code. At the end of the day my code is considerably cleaner, more declarative, and more composable.

I am curious as to why this feature is not one of the top discussed or actively developed proposals in the pipeline? In the current form it's already proving to be so useful and would be more so if it were supported in more places (e.g. on functions or plain object properties).

Any insight into this would be great, thank you!

# Logan Smyth (a year ago)

Keep in mind that the available implementations don't necessarily reflect the state of the spec, and that they are maintained two independent groups.

None of the current implementations reflect the current state of the spec, which has changed a lot over the last years. Babel for instance is also a project maintained entirely by volunteers, and it's only in the last couple months that someone has come forward with the time and energy available to make progress on implementing the new version of the spec. Incidentally this will also probably break all your existing code until new versions of the decorators you use are written to support the new spec, so remember that you're very much relying on an experimental feature.

As for supporting it in more places in the syntax, the more more places it has to support, the more work that will have to be done. Keeping function and such as things to be approached later means the current spec can iterate more quickly. It's hard to both iterate quickly and also support a broad feature set.

# Caridy Patino (a year ago)

look at the notes! we are moving forward, but it is cross-cutting into other class related proposals like public/private fields. we are being more cautious IMO.