You will be required to have JavaScript programming language. Finally, to use the Git repository of this book, the user needs to install Git.

The code files of this chapter can be found on GitHub:
https://github.com/PacktPublishing/MobX-Quick-Start-Guide/tree/master/src/Chapter02

Check out the following video to see the code in action:
http://bit.ly/2NEww85

Data is the lifeblood of your UI. Going back to the equation that defines the relationship between data and UI, we know that the following is true:

So, it makes sense to focus on defining the structure of data that will drive the UI. In MobX, we do this with the observables. Take a look at this diagram:

Observables, as the name suggests, are entities that can be observed. They keep track of changes happening to their values and notify all the observers. This seemingly simple behavior has powerful implications when you start designing the structure of your client-state. In the preceding diagram, every circle represents an Observable, and every diamond is an Observer. An observer can observe one or more observables and get notified when any of them change value.

Although you can change an observable directly, it is highly recommended that you use actions to do it. If you remember, in the previous chapter, we saw that actions are the ones that cause a state-change. The UI simply fires the actions and expects some observables to be mutated. Actions hide the details of how the mutation should happen or what observables should be affected.

The diagram below is a reminder that UI can modify the State only via an Action:

Actions introduce vocabulary into the UI and give declarative names to the operations that mutate the state. MobX embraces this idea completely and makes actions a first-class concept. To create an action, we simply wrap the mutating function inside the action() API. This gives us back a function that can be invoked just like the original passed-in function. Take a look at this code block:

import { observable, action...

Reactions can really change the world for your app. They are the side-effect causing behaviors that react to the changes in observables. Reactions complete the core triad of MobX and act as the observers of the observables. Take a look at this diagram:

MobX gives you three different ways to express your reactions or side-effects. These are autorun(), reaction(), and when(). Let's see each of these in turn.

autorun() is a long-running side-effect that takes in a function (effect-function) as its argument. The effect-function function is where you apply all your side-effects. Now, these side-effects may depend on one or more observables. MobX will automatically keep track of any change happening to...

The story of MobX revolves around observables. Actions mutate these observables. Derivations and Reactions observe and react to changes to these observables. Observables, actions, and reactions form the core triad.

We have seen several ways to shape your observables with objects, arrays, maps, and boxed observables. Actions are the recommended way to modify observables. They add to the vocabulary of operations and boost performance by minimizing change notifications. Reactions are the observers that react to changes in observables. They are the ones causing side-effects in the app.

Reactions come in three flavors, autorun(), reaction(), and when(), and distinguish themselves as being long-running or one-time. when(), the only one-time effector, comes in a simpler form, where it can return a promise, given a predicate function.