@eccegordo Thanks for the link, will check it out.
Yes its observers, requiring deferred changes and extra state to avoid recursion/feedback. Observers can cause chain reactions of other observers when they do a get or set and will fire multiple times if they observe multiple props that change.
I have used exactly that approach in places but you have to make sure that the underlying model/state cant be updated through any other pathway. This is why I’ve got serious with exploring immutable data types.
What you describe is in a way a repeat of the sensible top down flow pattern as you are setting from an authoritative point (ie an authoritative property) and the data flows to other properties more deterministically, but NOT via observers. Observers are the real evil.
If Ember 2.0 can provide the design patterns that make observers unnecessary and go as far as to deprecate their use in application code, it will go a long way to simplifying and reasoning about data flow.
Any-time an observer is used its a red flag that a “higher level action” should have occurred instead to cause state change “above” and the new state to flow “down”.