Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add transform for ES7 decorators #73

Open
SaladFork opened this issue Aug 15, 2015 · 3 comments
Open

Add transform for ES7 decorators #73

SaladFork opened this issue Aug 15, 2015 · 3 comments

Comments

@SaladFork
Copy link

The Ember 2.0 release blog post states:

As the JavaScript decorator proposal stabilizes, and as transpilers improve their implementations, we plan to adapt computed properties and other APIs to that syntax

Additionally, thanks to rwjblue/ember-computed-decorators, we can start using ES7 decorators in Ember apps today.

I thought I'd try to get a head start and as an exercise for learning AST transforms try and implement an ember-watson command for this transformation today. I've made some progress in my fork, but am hitting a roadblock:

  • The esprima parser that is used by default cannot handle ES7 decorators:

Error: Line 4: Unexpected token ILLEGAL

AssertionError: did not recognize object of type "ExportDefaultDeclaration"

Any direction for addressing this would be most appreciated 😄

@marcioj
Copy link
Collaborator

marcioj commented Sep 2, 2015

These issues with decorators were fixed upstream. I think that converting the computed properties for the decorator syntax would be a create addition.

@SaladFork
Copy link
Author

Awesome, thanks for the heads up!

Todo:

  • Ember.computed -> @computed
    • without dependent keys
    • with dependent keys
      • should replace .get lookups when possible
      • should warn if argument names clash with any variable names in function
      • should probably suggest manual inspection as new arguments can now be used
      • What to do about expanded props like foo.@each.bar or foo.[]?
    • with get/set functions
    • should leverage convert-prototype-extensions for .property() ->> @computed

Do we want these? In the same command or separately?

  • .readOnly() -> @readOnly
  • Ember Data
    • DS.attr -> @attr
      • without arguments
      • with arguments: type ('string'), options hash ({ defaultsTo: ... })
    • DS.hasMany -> @hasMany
    • DS.belongsTo -> @belongsTo
  • Ember.on -> @on
    • should leverage convert-prototype-extensions for .on() ->> @on
  • Ember.observer -> @observes
    • should leverage convert-prototype-extensions for .observes() ->> @observes
  • Other computed macros provided by ember-computed-macros such as @alias

Will put these in first comment to track progress once we decide what to include.

@elbeezi
Copy link

elbeezi commented Sep 3, 2015

Do we want these?

yes. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants