That is, running the program should not lead to unexpected surprises.
#THE OBSERVER EFFECT CODE#
We strive to make our applications easy to reason about because it leads to more maintainable code that is easier to debug and test. “Difficult to reason about” is a term that is commonly thrown around – but what exactly does it mean? Informally, it means being able to tell what a program will do just by looking at its code. For reasons we’ll cover in this post, observers are an anti-pattern and should be avoided, as it makes it difficult to reason about and to debug your application.
Sound familiar? Funnily enough, the same effect can probably be found in your Ember application if you use observers. This is often because of instruments that alter the state of what they observe in some manner. In science, the term “observer effect” refers to the changes that are effected on some phenomenon simply by observing it. Let’s get started! Side effects wreck projects I’d like to take you through a tour of refactoring away from observers in your application and freeing yourself from the shackles of the “observer effect”.
Today, I’d like to write about something that is close to all our hearts – observers and a topic I think about a lot – functional programming (FP). My awesome colleagues have written about patterns and best practices we use at DockYard, covering everything from the Ember Object model and better acceptance tests, to native inputs and closure actions.
0 kommentar(er)
