State Management: Redux vs. MobX

Redux was developed in 2015 by Abramhov and Clark based on concepts used in Facebook’s Flux architecture. MobX also began in 2015 and was originally called Mooservable by the dev team. It became MobX with the 2.0 release on 26 Feb 2016.

There are three parts to state management:

• The State, which is the source of truth for your application’s State.
• The View, which is a rendering of the current State.
• The Action, which is something that triggers a State change.

Bare Javascript passes State via property trees. A function needing State obtains the information via property drilling. Depending on a function’s layer depth, property drilling can introduce significant overhead.

Using State Management introduces a structured workflow in the application and makes obtaining the application State trivial.

Redux

Overview

Redux manages application state in a centralized repository. There is a single state in the application and it is immutable. It can’t be modified by the application. This is similar to how State is managed in Flux. Redux is designed to be a predictable container for application state.

Redux combines Flux and Functional Programming and uses an immutable State as a single, predictable, source of truth in the application stored in a Javascript object.

Implementation

Using Redux requires a considerable amount of ramp-up work. There is a great deal of boilerplate code, configuration, and to take advantage of some capabilities, developers must follow explicit coding patterns.?

Workflow

There are three main workflow components:

• The UI: The UI passes the user’s activity, or their Action, to the Event Handler.?
• The Event or Action Handler/Dispatcher: The Event Handler’s Dispatcher then notifies the Store of the Action.?
• The Store with Reducers and the State: The Store clones a copy of the current State for the Reducers to act on based on the user’s Action. On completion, the Store passes the new state to the UI. The updated State will trigger a refresh of any component accessing that State.

The State’s Reducers are responsible for updating the State of the Store. They are pure functions that analyze the Store’s recursive data structure. They do not mutate the current state, nor do they make external API calls. Using a combining function, they recombine the results.of their recursive processing into their constituent parts, thereby building a return value.

MobX

Overview

MobX was created in ES5 Javascript and follows Functional Reactive Programming patterns and prevents an inconsistent State by automatically performing all derivations. MobX’s main difference from Javascript and Redux are that State is not immutable and your application can automatically store different observable data types into different MobX Stores.

MobX uses abstraction to hide much of the background operation and reduce the boilerplate code requirement. MobX directly modifies its current state(s) without cloning beforehand.

Implementation

MobX is implicit by nature, and requires little boilerplate code. After implementing State storage in the desired data structure (plain, arrays, objects, etc.), set those properties that will change over time to observable for MobX tracking.

Workflow

There are four main workflow components:

• Actions
• Observable State
• Derivations (Computed Values)?
• Reactions (or Side Effects)

Events invoke Actions. Those actions can originate with the user or the application, and are the only thing that can modify the Observable State. MobX propagates any changes to the Observable State to all Derivations and Reactions.?

Deciding On A State Manager

Types of Derivations could be computation, serialization,? rendering, etc. and example Rendering side-effects are I/O activity, DOM updating, network activity. etc.

• Application Architecture – Is the architecture Flux/Functional Reactive Programming (Redux) or more OOP (MobX)?
• Ramp-up – Time until productive
• Boilerplate – Redux requires extensive boilerplate setup, MobX has very little boilerplate
• Learning Curve – Steeper: Redux requires developers to follow explicit coding patterns to access capabilities.?Flatter: MobX is more implicit and doesn’t require extra tooling. Setup is adding a class and setting Observers, Actions, and Compute Values.
• State Stores – Redux usually maintains a single immutable State even though it is possible to set up multiple Stores in Redux. It is a cumbersome process. MobX makes it much simpler to have multiple Stores and it uses changeable States.
• Purity – Redux uses pure functions and does not allow State modification. MobX allows mutable States.?
• Scalability – Redux’s pure functions make code scaling much simpler and predictable.? MobX’s workflow does not include many pure functions, making testing not as straightforward, and as the application grows it becomes more difficult to determine what exactly should an output be, given an input.
• Performance – Redux can suffer performance degradation from very frequent updates to its single State Store. MobX, on the other hand, with support for multiple Stores can better support frequent State updates, such as real-time updates on market pricing for a trading platform.
• Community Support and Tools – Redux has a much larger community and more widely tested tools. MobX has a smaller community and fewer tools.
• Debugging – Redux has a single source of truth and uses a pure Store making its output predictable and repeatable. Redux has better debugging tools, including ReduxDevTools and the Time Traveling Debugger (provides State history). MobX with its implicit nature, multiple States, and code abstraction can be very difficult to troubleshoot and determine the proper output from a given input. All State updates happen behind the scenes and do not offer any history. MobX also suffers from fewer robust tools

To learn more about State Management and to experience Eric Marcatoma ’s full Lightning Talk session, watch here .

This article was originally published as a part of the Learning and Growth series on the InRhythm blog .

This newsletter was curated by Kaela Coppinger . Thoughts or questions? Sound off in the comments section below.