Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Decorator Support RFC #440
Seems like this RFC aims to optimize for several things
And a couple of others that do not appear to be optimized for (only because they're not called out in the RFC)
Given that it's possible we may not be able to solve for all of these things at once, can we create a prioritization for these kinds of goals?
Absolutely, I think a clear outlining of constraints we are optimizing for will definitely help us in the future. I will call out right now that "Maintaining compatibility with both JS and TS decorators" is not a goal - with
referenced this pull request
Feb 13, 2019
I'm not sure the ability for addons to create / version / update decorators is important at this point. Are there a bunch of addons just waiting to get custom decorators into the wild? Since so much of this RFC is wrapped up in the details of keeping decorator version up to date and in sync I assume a lot of effort will need to be spent on this as well.
Wouldn't it be easier to just support official ember decorators right now?
Since the invocation syntax isn't likely to change this would mean the community could fully embrace the official ember decorators knowing that they will be kept up to date as the spec changes. Then when this reaches stage-3 in TC39 support for addons and apps to define their own decorators could be opened up and documented.
There are at least two fairly high profile addons that already use decorators in the classic world:
We could allow decorators to be written and applied, but not provide any support and rely on addon authors keeping their decorators up to date, but that seems like it would hamper the community. We could also allow a specific set of community decorators to be used, but that seems highly arbitrary. That's why we ended up on the proposal in its current form.
@pzuraq I think the level of complexity in keeping up to date identified by @mike-north is a much larger hindrance to community adoption than it would be to tell addons that they are on their own for staying up to date with changes to the spec.
Speaking only for myself I'm highly unlikely to update my app to native classes / decorators with these complicated caveats. It is simply too much for me to worry about and learn. This is coming from someone who is very excited to make this change!
I would be much more willing to trust Ember's official decorators along with those from these significant major addons that I believe the community will support any moves. I don't think
is actually a bad path. There is risk in adopting decorators at this point and mitigating that risk across experimental addons adds complexity that seems scary to me.
chriskrycho left a comment
This is a solid update; thanks for putting it together! From the perspective of one of the ember-cli-typescript maintainers, this is a solid plan.
I will note that we should be very clear about the differences—and I'll try to make sure we hit this in the docs we're putting together for the final ember-cli-typescript v2 release over the next two weeks—between v1 decorators in Babel and in TS.
Does anyone have a handy guide to those differences? If not, I'll see if we can put one together as part of that documentation process.