The story of Redux, and more...

Redux is a predictable state container for JavaScript apps. Evolving from the ideas of Flux, while avoiding its complexity by taking cues from Elm, Redux has a minimal API footprint.

Yesterday, we had an incredible Redux AMA session hosted by its creators, Dan Abramov, and Andrew Clark.

Their insightful answers touched upon topics ranging from the genesis story of Redux, aspects of Redux borrowed from Elm, the roadmap for Redux; and great pieces of development advice.

Following is a short summary with excerpts from Dan’s and Andrew’s answers; for the full unabridged treasure trove of Redux information, the AMA page should be your destination.

A Brief History of Redux

Dan was a Flummox user — a Flux library created by Andrew — in early 2015, using it as part of his React DnD library; which was the prominent precursor for the meeting of the Redux creator duo.

According to Andrew, the “Flummox” ideas of action creators as functions returning action objects; using React components (and higher-order components) to connect to an app’s stores (instead of mixins as most libraries did at the time); were pretty influential in the design of Redux.

Dan came up with “Redux” while working on a talk for React Europe 2015 on time-travel and hot reloading Flux stores. Back then, Redux had "stateless stores" that returned a new state given the previous state and an action (known as reducers, now).

Based on Dan's idea of using composition for “stateless stores”, for a “combinedStore”, Andrew identified that one could also use function composition to avoid having to keep track of many "stateless stores", and that, I believe, was the birth of what we know as reducer composition, today.

Andrew’s overnight prototype had many of the key concepts that make up Redux today — reducer composition (combineReducers), a single state value, and selectors.

Andrew Clark

This updated design also had the happy side-effect of dramatically reducing the amount of code needed to implement Redux, as anyone who has completed Dan's Egghead Redux courses can tell you.

Middleware and enhancers followed soon after, and these concepts aided in keeping the core of Redux small and focused; and gave way for the community to innovate and extend Redux. Amazing community projects like redux-saga and redux-observable stand testament to this fact.

Apart from the obvious purpose of the following links serving as good education material on the evolution timeline of Redux, we sense a wee bit of nostalgia, Dan. 😄

Dan Abramov

I suggest to read early issue and PR discussions, they're a lot of fun to revisit now.

Read the complete answers here.

Redux is inspired by Elm

Redux documentation is pretty vocal on the fact, that a few aspects in Redux borrow inspiration from Elm. However it is quite intriguing to know that the creators of Redux realised this only after working on Redux for a while.

Andrew Clark

Dan and I weren't too familiar with Elm when we first started working on Redux. We had read the Elm Architecture document, but for whatever reason, neither of us really understood it.

It was only later, after coming up with "reducers" and reducer composition independently, did we realize how similar Redux is to Elm.

Dan emphasises the aspects of Redux that are similar to Elm’s Architecture concurrently explaining the differences between Elm and Redux … pretty spot on!

Dan Abramov

In particular, Redux reducers are similar to "update" functions in Elm, and Redux combineReducers() is a helper for a pattern that is also used for creating a hierarchy of update functions on Elm.

The major difference is that Elm Architecture is "fractal", that is, it usually describes hierarchical UI, and like React components, always nestable.

In Redux, however, there is always a top-level "entry point" (store), and so some things inherently live on the top level (such as middleware). This makes it harder to reuse components coupled to Redux because they assume a specific top--level state shape, or a specific middleware.

Elm Architecture also models complete UI, whereas Redux is typically used solely for the "model", and the role of UI is often given to React.

Read the complete answers here and here.

When did you realise that Redux is popular?

When asked about the realisation on the increasing popularity of Redux, Dan and Andrew had the following to say

Dan Abramov

I realized Redux was getting popular when it was still a proof of concept for my upcoming talk and had about 300 stars. I went to bed and woke up next morning to a list of 15 small Redux examples that popped up on the net.

Andrew jumped on the Redux ship, deprecating his own popular Flummox library after getting acquainted with Redux … absolutely ❤ Andrew’s open source advice in this context

Andrew Clark

My open source advice is this: you are not competing against other libraries. Work on finding the best solutions, regardless of whether that's by collaborating on someone else's project or starting your own.

Read the complete answers here.

What should be learnt first — Redux or React?

Andrew Clark

Learn React — how its component model works, how data flows through an app, and how setState is used to update — before digging into Redux. I believe that is the best avenue for success.

Although Redux can technically work with any UI library, its design was heavily influenced by its relationship to React. For example, both libraries promote immutability and unidirectional data flow.

Read the complete answer here.

Getting started with React/Redux

Dan Abramov

Build an app with React itself. When it's large, you might notice some components get extremely large and buggy. This is a good point to perhaps introduce some Redux into it.

Most importantly, learn things as you need them to build an app, don't try to learn everything at once.

react-howto is a good guide, and create-react-app is a good way to get started.

Read the complete answer here.

Can a complex app be built without Redux?

Dan has written an article in this context — You might not need Redux. The gist of the article, as Andrew has aptly put in the following answer is this: Only move it into Redux once it becomes necessary.

Andrew Clark

You can get pretty far without a state management solution like Redux, but for any non-trivial app, I wouldn't recommend it. But as I've said in a few responses already, I don't think it's wise to put everything into your Redux store.

The rule of thumb I follow is: when in doubt, implement your state using React component state (that doesn't mean you can't use a reducer). Only move it into Redux once it becomes necessary.

Read the complete answer here.

How to avoid “anti-patterns”?

Dan Abramov

Don’t worry about “anti-patterns”, just do what makes sense to you as long as you don’t ship too many bugs.

There is a whole industry (educational content, conferences, consulting) revolving around selling “best practices” and cures for “anti-patterns” so my advice is to be chill about them ;-)

Read the complete answer here.

Facebook uses Redux

According to Dan, teams at Facebook have the liberty to use whatever tech they want. As Andrew puts it; being its creator, a heavy use of Flux architecture at Facebook is anything but natural, and Redux has started gaining some adoption as well.

Andrew Clark

As far as I can tell, Redux is being used in a few dozen places, including a new implementation of the blue navigation bar that we've been testing.

Dan Abramov

I think some parts of website also started to use it but those are subject to change because sometimes people want to customize it for their needs. Don't forget Redux is super tiny so adding or removing it is not a huge deal.

Read the complete answers here.

The Future of Redux

Apart from a few extensibility design changes (without any changes to user facing APIs), and new minor API implementations, Dan and Andrew are content with Redux as a complete product.

They also do let know of their motivations to make React components Redux-y. In their own words…

Dan Abramov

Personally, I will be interested in making React component state more competitive with Redux.

Andrew Clark

There are a few things that I would still like for Redux to solve. One is to make it easier for Redux-like patterns to be used at the component level. It's likely that this problem is better solved at the React level.

Read the complete answers here.

Apart from the above excerpts; Dan and Andrew have also given answers to a wide variety of other topics … benefits and pitfalls of Immutable; on maintaining component wise state in React; Async and Redux, and more…

Don’t scroll up. Here is that link to that AMA page again. You’re welcome! 😬