Currently, when you define a binding on a class, the properties upon which the binding depends will be retrieved at the moment of object instantiation. This has the adverse effect of eagerly triggering computed property calculations. This could be detrimental if those calculations are expensive and the results are never used.
App.Project = Em.Object.extend({
contributors: function() {
var contributors = Em.A();
// Expensive call to a remote server
$.ajax({ ... });
return contributors;
}.property(),
contributorCountBinding: 'contributors.length',
});(Complete working example: http://jsbin.com/onofuv/7/edit)
When we instantiate a project, we don't want to make a remote call until it actually needs that property.
We think there are at least two ways Ember could handle this:
- When setting up the observer chain, it could pause when it encounters a cacheable computed property that has not yet been cached (much like it pauses when encountering an undefined value). (There would still be a problem with volatile computed properties.)
- It could delay creation of the observer chain until the dependent property is actually requested via
Ember.get().
Currently, when you define a binding on a class, the properties upon which the binding depends will be retrieved at the moment of object instantiation. This has the adverse effect of eagerly triggering computed property calculations. This could be detrimental if those calculations are expensive and the results are never used.
(Complete working example: http://jsbin.com/onofuv/7/edit)
When we instantiate a project, we don't want to make a remote call until it actually needs that property.
We think there are at least two ways Ember could handle this:
Ember.get().