Why MobX?

Written by eugenkiss | Published 2018/01/14
Tech Story Tags: javascript | mobx | reactive-programming | programming | developer-experience

TLDRvia the TL;DR App

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:

Addendum

Michel Westrate, the author of MobX, uses the phrasing “managing data flows” to describe what MobX does.

“Probably, it is more accurate to talk about MobX as a data flow library, that enables you to roll your own state management architecture with minimal effort” Source

In the context of this article “managing data flows” and “state management and change propagation” are equivalent.

The article focused on MobX's usage together with React. It is important to mention that MobX is in no way tied to React—MobX is an independent library. For example, it is successfully used in Angular projects. There are even usages outside of the scope of GUI programming.

The article 8 No-Flux Strategies for React Component Communication has a good overview of the different approaches to component communication in React without MobX.

Now, I did not forget about the elephant in the room which is Redux and its flavors. This is a topic for another article. In any case, there are already quite a few comparison articles for the curious. I also did not mention MobX State Tree. Primarily because I haven’t used it yet. It seems to be an awesome project though!

The article has been published on the Zalando Tech Blog as well!


Published by HackerNoon on 2018/01/14