Dan Abramov, the creator of Redux recently published an article “You Might Not Need Redux” where he pointed out that developers opt Redux as a de facto when building React apps, without even considering if they actually need it.

Redux is not to be blamed. Like any other library, it offers some tradeoffs like touching three files to achieve simple tasks, describing the state and actions as plain objects and arrays and handling the logic via pure functions. These constraints enable easier debugging, better testability, guarantee the user-interface to be predictable with the state and a lot more out-of-the-box.

But, writing so much to do so less brings in some annoyance and slows down the overall development.

Do we really need a state management library?

Can’t we just define plain ES6 classes as models and store their instances in an array collection without using a library? Yes, we can! But, the problem isn’t the data storage or retrieval.

The real problem is how do we detect data mutation and handle its side-effects. Side-effects of data mutation includes actions like

Syncing the UI with the change in data

Re-calculating the computed variables

Navigating to a different route

If we mutate the data using assignment operator (like user.name = “John Doe”), we don’t have a mechanism to detect the change (Object.observe() has been deprecated).

That’s exactly where we need state management libraries.

Redux detects such changes by enforcing data mutation via pure functions called reducers.

How other frameworks solve it?

Dirty checking: Angular 1.x uses “dirty checking mechanism” where the new and old data tree are deeply compared in successive cycles. It is tempting at first but kills the performance at scale.

Angular 1.x uses “dirty checking mechanism” where the new and old data tree are deeply compared in successive cycles. It is tempting at first but kills the performance at scale. Reactive programming: Angular 2 and Meteor use the concepts of reactive programming which makes data propagation and change detection easy to understand and scale.

Angular 2 and Meteor use the concepts of reactive programming which makes data propagation and change detection easy to understand and scale. Observer pattern: Similar to reactive programming concepts, Observer pattern triggers events on data mutation. Knockout.js and MobX use observer pattern.

Similar to reactive programming concepts, Observer pattern triggers events on data mutation. Knockout.js and MobX use observer pattern. Setter and Getter: The good old setter and getter methods have solved the problem of change detection for years which has been used by Ember and Backbone.

What are the alternatives to Redux?

this.setState()

React comes with it’s own method of change detection at the component level. If you’re new to React, just stick to this.setState() approach. It works well for small apps. For eg: Simple Todo App

Reactive and Observer patterns with React

MobX (aka mobservable ) : It has a very small footprint. If you’re comfortable using object-oriented pattern, this one is for you. With the use of ES6/7 decorators you hardly feel you’re using any library.

) It has a very small footprint. If you’re comfortable using object-oriented pattern, this one is for you. With the use of ES6/7 decorators you hardly feel you’re using any library. RxJS: “The Reactive Extension of JavaScript” as they call it. RxJS is a beast in itself. In simple terms, RxJS = Observables + Operators + Schedulers. Though it’s famous as a standalone library, it has some neat bindings for React.

Other Flux implementations