When Ember.observer should be used?
Lots of observers can be the source of hard to debug issues and they can have a big impact on the performance of your app. You should avoid them as much as possible.
They still serve a purpose, but their main reason of existence is for the internals of the framework and for Ember apps to communicate with the outside world.
Observers are used heavily within the Ember framework itself, but for most problems Ember app developers face, computed properties are the appropriate solution. Ember v2.8.0 - The Object Model
The end result of an observer and a computed property is the same, except that computed properties are lazy loaded and cached.
Demo: Ember runloop demonstration with a computed property and an observer
Usually what happens is that a computed property is not being re-calculated and updated as it was expected to do so and the quick fix is to use an observer instead. That is not a fix, it is a band aid. In a follow up article I'll cover how to fix computed properties that doesn't seem to work consistently.
observers are the data binding hammer, but few things are truly nails
Observers are the right tool when syncing data that is being shared with another application. The usual examples are apps that do data visualization or maps rendering. The data that an Ember app is holding might be modified by the other app and we must be notified of those changes so that both apps are always in sync.
Some Examples:
// icon observer separated from generated (leaflet properties) due to a
// leaflet bug where draggability is lost on icon change
iconDidChange: observer('icon', function() {
this._layer.setIcon(this.get('icon'));
popupOpenDidChange: observer('popupOpen', function() {
sizeChange: Ember.observer('measurements', function() {
contentDidChange: Ember.observer('content.@each.isLoaded', function() {
// add redraw logic here. ex: