ember.js: Some unconsumed computed properties are triggering observers

I’m not sure if this is a bug, or an intentional change and the documentation hasn’t been updated, but it broke a bunch of my code when I updated to Ember 1.7 so I figured I’d point it out to either have it fixed, or have the documentation updated.

http://emberjs.com/guides/object-model/observers/#toc_unconsumed-computed-properties-do-not-trigger-observers explains that unconsumed computed properties do not trigger observers. However, it appears that as of Ember 1.7, this isn’t true of certain computed properties, namely Ember.computed.alias(), Ember.computed.readOnly() and Ember.computed.oneWay() (maybe others – I’ve only tested a few).

Consider the following script snippet:

var Object = Ember.Object.extend({
    value: "initial value",
    alias: Ember.computed.alias('value'),
    oneWay: Ember.computed.oneWay('value'),
    readOnly: Ember.computed.readOnly('value'),
    bool: Ember.computed.bool('value'),
    manual: Ember.computed('value', function () { return this.get('value'); }),
    computedDidChange: Ember.observer('alias', 'oneWay', 'readOnly', 'bool', 'manual', function (obj, key) {
        console.log("Observer fired for: " + key);
    })
});
var object = Object.create();
object.set("value", "new value");

When I run this under Ember 1.6.1, it produces no console output. When I run it under Ember 1.7.0, it produces:

Observer fired for: alias
Observer fired for: oneWay
Observer fired for: readOnly

All the computed properties are unconsumed, but the alias, oneWay and readOnly computed properties triggered observers, while the bool and manually-specified computed properties did not.

Perhaps this is desired and the documentation just needs updating, but is it really intentional that it would be inconsistent, and certain computed properties trigger observers when unconsumed while others do not?

About this issue

Original URL
State: closed
Created 10 years ago
Comments: 15 (15 by maintainers)

Commits related to this issue

Do not observe computed properties that are not consumed - Ember docs state that computed properties that are not consumed will not trigger observers, unfortunately this is not true for readOnly ... — committed to npars/ember-i18n by npars 8 years ago

Most upvoted comments

My idea is observer should observe 😉

Yes observers should observe, just as accessors should be lazy/on-demand.

If accessors need not be lazily, then they should just be properties set within the constructor init().

export default Ember.Object.extend({
  init() {
    this.fullName = 'Charles Bourasseau';
  }
});

If a computed property (an enhanced accessor) happens to be required eagerly, the developer can opt into this behavior explicitly but accessing the property when appropriate (maybe within the init or in the appropriate hook: didInsertElement).

This allows for all existing behavior to continue to work, and eagerness to be explicit and opt-in.


export default Ember.Object.extend({
  init() {
    this._super(...arguments);

    this.get('fullName'); // ensure fullName is initialized eagerly
  },

  fullName: computed('first', 'last', function() {
    return `${this.get('first')} ${this.get('last')}`
  })
});

That being said, using observers should be quite rare and far between – typically for when writing to 3rd party libraries like d3 or similar (I speak about this in more detail here)

The state of the world is not changed

The order data is loaded is very much state changing.

It’s just about performance.

Which shouldn’t be dismissed, its a real constraint.

stefanpenner on Mar 12, 2017