Wicked Good Ember 2015 - The Observer tip-jar by Stefan Penner
Why Stack Overflow recommends it
Stack Overflow users link it when explaining why Ember observers are discouraged and how to refactor code to avoid them.
Recommended by 2 people across 3 different months, 2015 to 2016.
What it is
A 33-minute conference talk from Wicked Good Ember 2015 by Stefan Penner, published by Confreaks. It explains the difference between computed properties and observers in Ember.js and argues for avoiding observers in favor of computed properties and data-flow patterns.
What people said
Recommends kristjan reinhold · 2015-09 · Stack Overflow · on “How do I control ember component observer execution order?”
The "dont user observer" idea i got from this : [this video] Wicked Good Ember 2015 - The Observer tip-jar by Stefan Penner. You could maybe add a little hook . Ember.run.later(function() { dostuff }, 300); So you could manually have control over the order
Recommends kristjan reinhold · 2015-10 · Stack Overflow · on “Ember's notifyPropertyChange() does not fire observers of wrapped component”
Observers are bad practise in general, i provided u a decent solution but what the heck. Just to clarify why: [this video]
Recommends user1429980 · 2015-11 · Stack Overflow · on “EmberJS: Refactoring Model Observers”
I have a model with several observers, and after watching Stefan Penner's talk [this video] on removing observers, I'd like to do the same with mine [LINK] : import DS from "ember-data"; import Ember from "ember"; import TimeableMixin from "../mixins/timeable"; export default DS.Model.extend(TimeableMixin, { employer: DS.belongsTo("company", {async: true}), updateDescription: function() { let description = ""; const hasOccupation = !Ember.isBlank(this.get("occupation")), hasEmployer = !Ember.isBlank(this.get("employer.name")); if (hasOccupation) { description += this.get("occupation"); } else { if (this.get("type")) { description += `${Ember.String.capitalize(this.get("type"))} Job`; } else { des
Cites bmac · 2016-02 · Stack Overflow · on “EmberJS, understanding DS Model life cycle”
The 'isLoading', 'isLoaded' and 'isSaving' properties are all implemented as computed properties. In Ember, computed properties are lazy and do not compute their state until they are requested for the first time using .get or displayed in a template. So despite the fact that conceptually we as developers may know the value of isLoading is changing and will return a different value when record.get('isLoading') is called, as far as Ember is concerned the value of isLoading is undefined until some code explicitly asks Ember for that value and Ember takes the time to compute its state. As a result, when you use Ember.observer to watch a computed property it will not be able to detect changes in
Cites Ember Freak · 2016-08 · Stack Overflow · on “What is the ember way to communicate from "parent" to "child" component ?”
You can bind parent-component property to child component, and you can react to parent component property change without an observer through components hook. This will adhere Data Down Actions Up(DDAU) principle and avoided observer. Ember-twiddle [LINK] In the below example, whenever selectedOptionId changed in parent-component, then in child component(my-table) will start rerendering by calling following hooks in the order ( didUpdateAttrs , didReceiveAttrs , willUpdate , willRender , didUpdate , didRender ). You will get newAttrs and oldAttrs property from options argument from didUpdateAttrs and didReceiveAttrs hook. For first time rendering there won't be options.oldAttrs in didReceiveA