Main idea State is at the heart of every application and there is no shortcut creating a buggy, unmanaged application. Therefore, many solutions state management attempts to limit the ways in which it can be change, for example, make the state immutable. But it encourages new problems, the data needs to be normalized, there is no guarantee of referential integrity and such powerful concepts as prototypes become practically impossible. Conceptually, MobX works like groups and chats in messengers, there is an observer , it monitors changes in the states to which it is subscribed, and there is an action that changes this state. Events, reactions, and calculated and observed values. Observable state. Any value can change and be a source for calculated values, and there is a state. MobX can make many types of values ​​(primitives, arrays, classes, objects, etc.) and even (potentially circular) references observable out of the box. Computed values. Any value can be computed using a function that exclusively uses other computed values. Computed values ​​can range from concatenating multiple strings to producing complex objects and visualizations. Since the calculated values ​​are observable by themselves, even the display of the entire UI can be inferred from an observable state. Calculated values ​​are calculated either lazily or in response to state changes. Reactions. The response is a little closer to the computed value, but instead of producing a new value, it contributes to a side effect. Reacts combines reactive and imperative programming for things like typing to the console, making network requests, incrementally updating the React component tree to update the DOM, and so on. Actions. Actions are the primary means of changing state. Actions do not respond to state changes, but borrow sources of change, such as user events or incoming web socket connections, to change the observed state. When using MobX, the dependency tree has a minimal size. For example, once a person is given an alias, outputting the value of fullName, first name, or last name will no longer affect rendering. All observer relationships between these values ​​can be cleared and MobX will automatically simplify the dependency tree. How does Mobx work? Derivatives will automatically respond to state changes. All reactions are synchronous and, more importantly, without failures. When the observed value changes, the following algorithm occurs: 1. An observable sends a notification to all of its observers that it has expired. Any affected computed values ​​will be recursively passed to their observers. Observers that will become obsolete when the value of “1” changes. These are all derivatives that may be affected by the change values. 2. After sending the stale data notification and saving new value, a ready notification will be sent. This notification indicates if the value has changed. 3. Once the derivative receives a ready notification for each stale data notification received in step 1, it will be notified that all observed values ​​are stable and start recomputing. Counting the number of ready/stale notifications ensures that, for example, the computed value “4” will be reviewed only after the calculated value of “3” becomes stable. 4. If none of the ready notifications indicate that it has been changed, then the derivative will simply tell its own observers that it is ready again, but without changing its value. Otherwise, the calculations will be recalculated and send a notification to their own observers about readiness. As a result, this order of execution occurs. Note that the last reaction will never be executed if the computed value "4" is recalculated but does not give a new value. You can also understand that a reaction is essentially a computed value that is always in reactive mode. It is important to understand that the algorithm can be implemented very efficiently without closures and only with the help of many arrays of pointers. In addition, MobX applies a number of other optimizations.