rwjblue / ember-cli-esnext

35 stars 7 forks source link

Add support for ES6 classes to extend Ember classes (e.g. Ember.Object) #7

Closed jayphelps closed 9 years ago

jayphelps commented 10 years ago
class Person extends Ember.Object {
  init() {
    // do work, son.
  }
}

This is easier to do with traceur since they abstract class creation to a runtime function $traceurRuntime.createClass. I'm not sure how we would do it with esnext. Seems like we'd have to override the output itself some how.

I have no idea how we'd support observers, computed properties, etc...This is prolly a "big picture" issue with Ember long term.

For example, this is not valid ES6:

var foo =  {
  init() {

  }.property()
  /// Unexpected token .
};

@Annotations maybe?

knownasilya commented 10 years ago

@jayphelps according to @rwjblue using Ember.observer and Ember.computed directly is the recommended way going forward, since the syntactic sugar might be an optional addon in the future.

jayphelps commented 10 years ago

@knownasilya Got it. Can you share an example in the context of an ES6 class?

This doesn't work obv:

class Foo extends Ember.Object {
  // Can't use expressions around class methods
  Ember.computed(someProperty() {

  })
}

This in theory should work (untested):

class Foo extends Ember.Object {

}

Foo.prototype.someProperty = Ember.computed(function () {

});

But clearly that's less than ideal. Just looking for clarification.

knownasilya commented 10 years ago

Yeah, not really sure.

Is the following not valid?

class Foo extends Ember.Object {
  someProperty: Ember.computed(function () {
    // code here..
  })
}

Yeah, seems like the only way is with prototype, kinda lame..

jayphelps commented 10 years ago

@knownasilya nope.

ClassElement
  : MethodDefinition
  | static MethodDefinition
  ;
MethodDefinition
  : PropertyName ( StrictFormalParameters ) { FunctionBody }
  | get PropertyName ( ) { FunctionBody }
  | set PropertyName ( PropertySetParameterList ) { FunctionBody }
  ;

Cc/ @rwjblue for clarification

knownasilya commented 10 years ago

@jayphelps I think that's the point of the getters/setters, to not have to write Ember.computed/observer, since that's what it does at the heart of it.

jayphelps commented 10 years ago

@knownasilya As far as ES6 goes, AFAIK getters/setters are still only the computed part. Without caching, run loop, observing, binding, etc. Would love to be wrong, but last time I was reading the latest spec that was my take away.

knownasilya commented 10 years ago

@jayphelps yup :) but they make it possible to do those things without needing Ember.computed. We'll be able to do something with annotations ultimately.

class User extend Ember.Object {
  @computed firstName, lastName
  name() {
    return this.firstName + ' '  + this.lastName;
  }
}

Some of the other ES6 features come into play as well, like Object.observe & Proxies. I think the runloop and caching will be Embers, with modifications of course.

jehrhardt commented 9 years ago

What is about using sweet.js macros to translate es6 class syntax to es5 Ember code?

knownasilya commented 9 years ago

@jehrhardt that's not a bad idea, could be a nice ember-cli preprocessor addon.

listepo commented 9 years ago

+1

stefanpenner commented 9 years ago

this library is deprecated in-favor of ember-cli-babel. As esnext + babel essentially merged forces.

perlun commented 7 years ago

For reference, here is ember-cli-babel.