EmberJS, DS Model Life Cycle Understanding

Question

I am trying to monitor state changes in my DS models.

Interesting flags were found in the documentation:

• isLoading
• isReloading
• isSaving

And they work correctly in templates, I can play with {{#if model.isLoading}}Is Loading{{/if}} , for example.

But it is very disturbing that the observers in these flags have very random behavior. For example, I found that the observer over the isSaving apartment isSaving not work at all. But the observer on the isReloading flag works fine.

Here I have a complete example of what I have tried so far. I have included this Mixin in my model:

 // app/models/mixins/loading-monitoring import Ember from 'ember'; export default Ember.Mixin.create({ isReloadingDidChange: Ember.observer('isReloading', function() { console.log('LOG: isReloadingDidChange', this.get('id'), this.get('isReloading')); }), isSavingDidChange: Ember.observer('isSaving', function() { console.log('LOG: isSavingDidChange', this.get('id'), this.get('isSaving')); }), isLoadingDidChange: Ember.observer('isLoading', function() { console.log('LOG: isLoadingDidChange', this.get('id'), this.get('isLoading')); }), isLoadedDidChange: Ember.observer('isLoaded', function() { console.log('LOG: isLoadedDidChange', this.get('id'), this.get('isLoaded')); }), onInit: Ember.on('init', function() { console.log('LOG: init', this.get('id')); }), onDidLoad: Ember.on('didLoad', function() { console.log('LOG: onDidLoad', this.get('id')); }), }); 

And I'm trying to call all of these observers, but only some of them start:

 > $E.toString() "< reports-dashboard-client-app@route :application::ember1553>" > var report; $E.store.findRecord('report', 14).then(function(r) { report = r }); Promise {_id: 438, _label: undefined, _state: undefined, _result: undefined, _subscribers: Array[0]} LOG: init 14 XHR finished loading: GET "http://myapi.com/reports/14". LOG: onDidLoad 14 > report.toString() "< reports-dashboard-client-app@model :report::ember1554:14>" > report.get('title') "new title" > report.set('title', 'title modified') "title modified" > report.save() Class {__ember1453996199577: null, __ember_meta__: Meta} XHR finished loading: PUT "http://myapi.com/reports/14".send > report.reload() LOG: isReloadingDidChange 14 true Class {__ember1453996199577: null, __ember_meta__: Meta} XHR finished loading: GET "http://myapi.com/reports/14".send LOG: isReloadingDidChange 14 false 

What am I missing?
How can I observe the state of the model and respond to changes: loading, ready?

Answer 1

The properties 'isLoading', 'isLoaded' and 'isSaving' are implemented as computed properties. In Ember, computed properties are lazy and do not calculate their state until they are requested for the first time using .get or displayed in a template. Therefore, although conceptually we, as developers, can know that the isLoading value changes and returns a different value when calling record.get('isLoading') , because the Ember value has the isLoading value equal to undefined, while some code explicitly requests Ember for this value, and Ember takes time to calculate its state.

As a result, when you use Ember.observer to view the computed property, it will not be able to detect changes in the computed property until any other code tries to access the value of the computed property.

Observers also have several other messages that you might want to know about. @stefanpenner talks well about its problems https://www.youtube.com/watch?v=vvZEddrClAQ and why they should be used sparingly.

In order for your mixin to fire observer events, you will need to access these properties anywhere. The best place for this seems to be in your onInit function. If you add this.getProperties('isReloading', 'isSaving', 'isLoading', 'isLoaded'); into the onInit function, then Ember will calculate these values, and observers will run correctly when the values ​​of these properties are changed.

DS.Model Life Cycle

Under the hood, Ember Data stores a state machine for recording recordings. This state machine is used to track record relationships with the server. At a high level, these are states in which an Ember Data record can be written:

• empty
• loading
• loading
  • created
    • unfinished
    • Sat down
  • saved
  • updated
    • unfinished
    • Sat down
• deleted
  • saved
  • unfinished
  • Sat down

empty Is the state in which each entry begins its life. Another thing is that this empty fact is not very important.

loading Is the state a record when Ember Data requests data from the server for the first time.

loaded Is the state a record when Ember Data receives some information from the server about the record. It has several subnets that are used to track changes made to the local record that were not saved on the server. If the record is created on the client side, it will be placed directly in the loaded.created.uncommitted state.

deleted is the transfer for deleted records. The deleted.saved deleted.saved means that the server has confirmed the deletion of this record. The deleted.uncommitted deleted.uncommitted means that the record was deleted locally, but record.save() not called.

The current state of the record is displayed by the currentState property in the record. isLoading , isLoaded and isSaving are all aliases for currentState.isLoading , currentState.isLoaded , currentState.isSaving , since each state in the destination machine has predefined values ​​for all of these properties.

I hope this DS.Model machine state explanation helps.

As an additional thing to check, are the lifecycle event bindings that appear in DS.Model instances. http://emberjs.com/api/data/classes/DS.Model.html#event_becameError