The WHY Behind MobX
I recently tried to submit a video about MobX to a E-Learning platform and was told that I needed to bring out more of the “why” of MobX. This got me thinking, what is really the why behind MobX?
My attempt to get the video accepted revolved around converting a self contained React component (using setState) to use MobX. It began by bringing out some of the companies listed on MobX’s GitHub page that use it.
If you are curious, some of these companies are Bank of America, Lyft, Wix, and Amazon Web services. You can find more information here: https://github.com/mobxjs/mobx/issues/681
Next I moved on to the issues of having actions, state, and computed values all within the same file. I introduced the flux framework and the ease it provides by following a one way data. By separating the actions, state, and components, one could more easily scale and provide better performance.
In the end the video was sent back…
The WHY…
Before I went back to the drawing board, I thought I might try googling “The why behind MobX”. One of the top results was MobX’s home GitHub page. I re-read the introduction to MobX and then it hit me. I was only giving half of the benefits.
MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP).
Yes MobX can follow the Flux framework and yes it allows scalability but it’s defining power comes from it’s reactive nature.
One of the most interesting quotes I’ve found from Michel Weststrate (the founder of MobX):
Reacting to state changes is always better then acting on state changes.
What does this mean though? What is the difference between acting on a stage change and reacting? I like to think of the difference as compared to a chain. Chains are built by connecting one link to another link. If someone were to grab an end of the chain and shake it, that wave of momentum would be passed through each link one by one. Which causes reactions to all of the links.
On the contrary, acting on the change would be for someone to see the chain wave then turn around and shake a separate chain. Thus acting because of a change rather than reacting because of a connection.
Acts vs Reactions
Coming from actively working in Redux, I can see the difference between acting on changes and reacting. Redux provides containers and a connect method that accepts manual subscriptions. This requires a programmer to know exactly which actions and state are needed within the children components. So that the correct data is imported into the connect, then passed as props to the child component.
The manual nature requires the actions and state that are being passed down to actively be checked and removed by the programmer. If actions or state are no longer being used it needs to be removed. Instead of manual subscriptions, MobX supplies the observer keyword.
Observers
Observable values used within a component are watched when the Observer keyword is applied to a component. The observable data sends notifications to all observers when data has changed. The observers are smart enough to handle if the change actually affects it’s render or not. Thus checking at runtime which observer to observable relationships are needed and returning the smallest amount of these connections.
Michel gives us this summarized quote:
Coarse grained subscriptions like Flux-style store subscriptions are very susceptible to oversubscribing. When using React, you can simply tell whether your components are oversubscribing by printing wasted renderings. MobX will reduce this number to zero.
If you’ve used React and Redux in large production applications, you’ve probably seen when logging something to the console, there are multiple re-renderings happening. This typically grows when more data is connected to more components. While React’s virtual DOM is very fast, more and more renders can slow down your app.
If you think back to the chain and links analogy, by creating Observer components we are essentially creating links within the chain. We remove the manual subscriptions that instead act on data changes.
Conclusion
While MobX can follow the flux framework, it provides a more powerful benefit. It introduces functional reactive programming to state management. It removes vulnerable manual subscriptions and replaces connects with more individual component observers.
So while it creates more “smart” components, at scale it actually preforms better.
Here’s your proof: https://www.mendix.com/blog/making-react-reactive-pursuit-high-performing-easily-maintainable-react-apps/
More Info:
MobX vs. Redux
