Reputation: 1279
I am having trouble understanding the statement below and have read it multiple times unfortunately:
If you never get a computed property, its observers will not fire even if its dependent keys change. You can think of the value changing from one unknown value to another.
This doesn't usually affect application code because computed properties are almost always observed at the same time as they are fetched. For example, you get the value of a computed property, put it in DOM (or draw it with D3), and then observe it so you can update the DOM once the property changes.
This is part of
http://guides.emberjs.com/v1.11.0/object-model/observers/
An example of an observer is:
Person = Ember.Object.extend({
init: function() {
this.set('salutation', "Mr/Ms");
},
salutationDidChange: function() {
// some side effect of salutation changing
}.observes('salutation').on('init')
});
Does this mean that if I don't call
person.get('salutationDidChange')
it will be considered an unconsumed computed property, and it will not execute even if salutation
changes?
Upvotes: 1
Views: 100
Reputation: 37105
All they are saying is that if you have an observer function(){}.observes('salutations')
and you have a computed property salutations
like function(){}.property('otherValue')
, the observer won't fire when otherValue
only when the .property()
has been accessed and it returns a different value.
The example listed isn't related to the headline. A better example would be:
var auth = Ember.Object.extend({
isAuthenticated: false,
currentUser: function(){
// When foo.get('currentUser') is accessed I will trigger.
console.log('currentUser')
}.property('isAuthenticated'),
doThing: function(){
// When the value `currentUser` changes, I will trigger.
console.log('doThing')
}.observes('currentUser')
});
If isAuthenticated
changes, doThing
will not fire until you access currentUser
. The change to isAuthenticated
doesn't cascade through properties triggering doThing
implicitly.
Upvotes: 1