The mental model for MobX apps is geared towards thinking about the observable state. This itself is divided into the minimal core state and a derived state. Derivations are how we handle the various projections of the core state onto the UI and places where we need to perform domain-specific operations. Before adding more core state, think about whether it can be rolled in as derived state. Only when that is not possible should you introduce new core state.

We saw how an async action is quite similar to a regular action without much ceremony. The only caveat is when you have configured MobX to enforceActions. In that case, you have to wrap state mutations in the async code inside runInAction(). When there are several async parts within the action, flow() is a better option. It takes a generator function (denoted by function*(){ }) that is interspersed with yield to the various promise-based calls.

reaction() and autorun() offer extra options to control their behavior. They share most...