Ember 1.12 + Decorators

(Robin Ward) #1

I’ve just pushed out an upgrade to Ember version 1.12. It’s deployed here on meta and try, and we’ll keep a close eye before marking it as beta/stable. As usual, please report any regressions you see :smile:

I’ve also added ember-computed-decorators to Discourse in the process, which gives us a much nicer syntax for declaring computed properties:


area: function() {
  return this.get('width') * this.get('height');
}.property('width', 'height')


@computed('width', 'height')
area(width, height) {
  return width * height;

It uses the ESNext decorators feature, which means you don’t need to use this.get for the properties you’ve already declared as dependant.

IMPORTANT NOTE: To validate this syntax you need to use eslint instead of jshint – the project has been updated to have eslint configurations. You should install eslint for your favorite editor. Also make sure you install babel-eslint as a parser.

(Sam Saffron) #2

Looking at

@computed('width', 'height')
area(width, height) {
  return width * height;

Wouldn’t something like this work (in theory)

area(width, height) {
  return width * height;

If its already introspecting to get the @computed thing, then it could (in theory) find the dependencies by looking at the params?

(Robert Jackson) #3

A more complete example might help explain:

import computed from 'ember-computed-decorators';

// ..... <snip> .....
@computed('someKey', 'otherKey')
foo(someKey, otherKey) {
  // Do Stuff

The strings provided to @computed are not introspected at all. What is happening is that the method imported from ember-computed-decorators is called passing "someKey", "otherKey", and the actual function that is attached to the foo property in this particular object.

So the above snippet would actually be translated to something like:

foo: Ember.computed('someKey', 'otherKey', function() {
  var dependentProperties = this.getProperties('someKey', 'otherKey');
  originalFunction.apply(this, dependentProperties);

Generally, attempting to capture the argument names of a function is actually pretty hard to get right due to minification (where they would be changed to a and b which are not terribly useful as dependent keys to a computed…).

(Alan Tan) #4

@rwjblue Could I also clarify how set is intended to be used?

Since the property is also available in set, is it the intended behaviour to be able to do searchContext = context. I couldn’t deduce anything from your test cases and readme. so I’m a little confuse right now. :cat: :dog:

EDIT: Ah nvm the above. Just reread the Ember guides and set has to always be used in order for computed properties and observers to fire.