Closed jayphelps closed 9 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.
@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.
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..
@knownasilya nope.
ClassElement
: MethodDefinition
| static MethodDefinition
;
MethodDefinition
: PropertyName ( StrictFormalParameters ) { FunctionBody }
| get PropertyName ( ) { FunctionBody }
| set PropertyName ( PropertySetParameterList ) { FunctionBody }
;
Cc/ @rwjblue for clarification
@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.
@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.
@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.
What is about using sweet.js macros to translate es6 class syntax to es5 Ember code?
@jehrhardt that's not a bad idea, could be a nice ember-cli preprocessor addon.
+1
this library is deprecated in-favor of ember-cli-babel. As esnext + babel essentially merged forces.
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:
@Annotations maybe?