Ember.js — Functional Programming and the Observer Effect
Lauren Elizabeth Tan

So unless you’re working on a PR for Ember.js, stay away from observers.

I can see why you would want to replace the observer with a computed property in the “Removing an observer that sets a value on the component” example, but I don’t see a good reason for replacing an observer with didReceiveAttrs in every case, especially in a case where you need to check if the attribute in question has changed, eg:

Assume that “chart.redraw()” is an expensive DOM operation that has to happen when the component’s dimensions change.

The observer looks more readable to me and avoids using the, undocumented, didReceiveAttrs API. I would also expect it to get called less since it only gets called when the attribute has changed.

Would you still recommend removing the observer in this case?

Show your support

Clapping shows how much you appreciated Adam McGrath’s story.