Why MobX?

Removing the burden of state management

State management and change propagation are arguably some of the hardest challenges in GUI programming. Many paradigms promised to save us from their burden. Only a few remained. Among them is MobX and its flavor of Transparent Reactive Programming.

The MobX logo

To understand the appeal of MobX, it is helpful to first understand how React revolutionized GUI programming. Traditional approaches allow the description of the GUI’s initial state. Further GUI state transitions must be accomplished with references to GUI elements and piece-wise mutations. This is error-prone as edge cases are easily missed. With React you describe the GUI at any given point in time. Put differently, taking care of GUI state transitions, e.g. manipulating the DOM, is a thing of the past: Your GUI code has become declarative.

React’s crucial advantage is making the “how” of updating the GUI transparent. That idea is reapplied by MobX. Not for GUI manipulation code but instead for state management and change propagation. In fact, combining both React and MobX is synergistic since even though React nicely takes care of how to update the GUI, when to update the GUI remains cumbersome without MobX. Cross communication between components is the biggest pain point.

Let us explore an example in React and JavaScript illustrating MobX’s advantages:

The example represents a very simplified e-commerce page. Here is a demo and its live-editable source code. The behavior is as follows. Initially, your cart is empty. When you click on “Buy shampoo” your cart item count increases by one and the recently bought component shows “shampoo”. A click on “Buy soap” does the same for “soap”. You can also clear your cart. In the live example you will see that only the cart in the header is rerendered but not the header itself. You will also see that the recently bought component does not rerender when you buy the same product in succession.

Notice that the dependency between the observable variables itemCount and lastItem , and the components is not explicitly specified. Yet, the components correctly and efficiently rerender on changes. You may wonder how this is accomplished. The answer is that MobX implicitly builds up a dependency graph during execution of the components’ render functions that tracks which components to rerender when an observable variable changes. A way to think of MobX is in terms of a spreadsheet where your components are formulas of observable variables. Regardless of how the “magic” works underneath and which analogy to use, the result is clear: You are freed from the burden of explicitly managing change propagation!

To sum up, MobX is a pragmatic, non-ceremonial and efficient solution to the challenge of state management and change propagation. It works by building up a run-time dependency graph between observable variables and components. Using both React and MobX together is synergistic. I would go so far as to say that MobX is more than a library. It represents an attitude that may change your approach to programming as a whole. Dig deeper into the world of MobX with the following links: