Removing the burden of state management State management and change propagation are arguably some of the hardest in GUI . Many paradigms promised to save us from their burden. Only a few remained. Among them is and its flavor of . challenges programming MobX Transparent Reactive Programming The MobX logo To understand the appeal of MobX, it is helpful to first understand how React 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 . 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. revolutionized at any given point in time 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 the GUI, the GUI remains cumbersome without MobX. Cross communication between components is the biggest pain point. how to update when to update Let us explore an example in React and illustrating MobX’s advantages: JavaScript The example represents a very simplified e-commerce page. Here is a and its . 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. demo live-editable source code Notice that the dependency between the observable variables and , 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! itemCount lastItem 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: Pure Rendering in the Light of Time and State Becoming Fully Reactive: An In-Depth Explanation of MobX What’s all this Fuss about Data-Binding? Computed State: The Model-View Problem MobX — Like React, but for Data 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 has a good overview of the different approaches to component communication in React without MobX. 8 No-Flux Strategies for React Component Communication 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 as well! published on the Zalando Tech Blog
