Let’s head directly to the point.
MobX is based on transparently applying functional reactive programming (TFRP). i.e. This is a non-obtrusive tool for the state management needs. In case, you don’t know what state management is, read further; if you do, skip to the next heading.
The reactive approach of web development established that a certain state is nothing but a snapshot of various factors/properties at a moment. Basically, a set of properties defines what view should be rendered to the user and what data should the user be looking at in various components. In order to define, update and consume these state properties we rely on state management tools.
An event in the application causes a trigger of an action which modifies the state, which in turn updates the computed values and finally a reaction is triggered that shall update the state in various containers and components.
Action —-> State —-> Computed Values ——> Reactions
The state is generally represented using a class. Since there can be multiple states, you can have multiple state classes.
The state comprises of the factors which constitute the application state. Since all the factors defined in the state are reactive, they are declared ‘@observable’s.
Similar to the core factors or properties of the state, we choose to define the derived properties by marking them @computed. MobX makes sure to update the computed values as soon as the properties they are derived from are updated.
To be able to wrap your brains around this, just think of the lifecycle in 3 steps. Action, State Update and Reaction. Here, the state update consists of two steps, updating the direct and derived state properties.
No smart and dumb components
When using MobX there are no smart and dumb components. Just that the components are defined in a dumb manner. It’ll be ensured by MobX when the components are to be re-rendered.
Differences from Flux/Redux
While redux relies upon the functional and immutable approach. MobX is more object-oriented. MobX doesn’t require immutability. One can simply choose to mutate the state and get the same re-rendering results. So, the learning curve of MobX is not as steep.
Another difference between the two is that we need not declare actions in MobX, we can choose to directly mutate the state and it will still work. However, this is an anti-pattern and must be avoided. Details, of course, will be discussed in the posts to come.
It seems a single blog post won’t do justice to the wonder that MobX is at all. I’ll soon be posting more about it.