Ask anything to Redux

Redux is a predictable state container for JavaScript apps. Andrew Clark, co-creator of Redux, is hosting this AMA to answer any questions you might have. Andrew recently joined Facebook as a front-end engineer. It's a great opportunity for everyone to get in touch with Andrew and have his insights on Redux and various other topics.

Ask Redux about:

  • Redux
  • State management in React/JavaScript based apps
  • Recompose Library
  • Working at Facebook
  • Anything related to React, JavaScript etc

Hosted by:

Comments (68)

Add a comment
Jimmy Hamm's photo

Are you excited by the advancements in GraphQL, Relay. Do you think Relay would replace Redux in the future, or would it still hold its ground? What are your thoughts?

Andrew Clark's photo

Front-end engineer at Facebook

Yes! GraphQL is amazing, as anyone who has played with a GraphiQL playground can attest.

To really take advantage of GraphQL in a React app, you need some sort of centralized store for normalizing and caching all your data. At OpenGov, where I previously worked, we used Relay in production since September of last year. It's a fantastic solution for declarative data fetching. I don't think we ever had a bug related to data fetching hit production.

There is some awkwardness when you first get started with Relay, particularly around mutations, which still sometimes confuse me. I occasionally hear from people who are turned off by the verboseness of some of Relay's APIs. If that's your reaction, I encourage you to look past it and give it a shot. In my experience, Relay offers an incredible number of features for just a bit more typing. Relay 2 (an upcoming rewrite of Relay's core) will solve some of these problems as well, in addition to some great performance improvements.

Nandan N's photo

In your opinion, what's the best way to get started with real world app development in React/Redux?

Show all replies
Dan Abramov's photo

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. is a good guide. is a good way to get started.

Dean Radcliffe's photo

Redux is great and has given a new vocabulary for talking about things that is very functional and great. But middleware is an anomaly.

The idea that you can dispatch an action that will asynchronously dispatch other actions is very simple - but it muddles the idea of what an action is. It also confounds the search for what interleaving semantics are applied - for example - after I dispatch actions A and B, the store may recieve [B A' A'']

I find that it's best if Actions are thought of as items that are sequentially reduced into the store, and if a higher level streams library such as RxJS is in charge of interleaving streams with whatever semantics the application needs.

I think Redux is great in its core focus, but RxJS is great at controlling the behavior of an aggregation of streams, and is more flexible than middleware, so I recommend keeping asynchrony out of actions.

But I'm glad so many people have found their own particular ways of using it. And I love how it pushes the few modules of my system that are not pure functions out to the periphery.

Show all replies
Andrew Clark's photo

Front-end engineer at Facebook

I agree that the difference between a "dispatchable" (something you pass to the dispatch method) and a proper "action" (the actual object which is sent to the reducer) can be confusing. We struggled with the right terminology for distinguishing these concepts in the docs. We landed on "async actions" and "actions" but I've never been that happy with those terms.

Observables are, indeed, a great abstraction for dealing with asynchronous control flow. Have you heard of Redux Observable? It seems to be exactly what you're looking for.

Also, as I mentioned in a different response, "[the] reason the middleware API exists in the first place is because we explicitly did not want to prescribe a particular solution for async." My previous Flux library, Flummox, had what was essentially a promise middleware built in. It was convenient for some, but because it was built in, you couldn't change or opt-out of its behavior. With Redux, we knew that the community would come up with a multitude of better async solutions that whatever we could have built in ourselves.

Mary Lopez's photo

Hi Andrew, I've a couple of questions for you.

  • What was your role in building Redux; what improvements have you pushed to the library, apart from Dan Abramov's.

  • What is your role at Facebook, and what sort of work do you do?

Andrew Clark's photo

Front-end engineer at Facebook

Hi Mary!

For the first question, refer to my answer to James Clarke The tl;dr version is that Dan's idea was to replace Flux stores with reducers. My contribution was to use reducer composition and selectors. And then we both came up with middleware and enhancers. That's a gross oversimplification, though, so you should read the full response :)

Regarding my role at Facebook, it's currently my fourth day as an employee, so for now I'm part of something called engineering bootcamp, which all new engineers participate in. After that I'll be joining the React team with Dan, which I'm super pumped about!

Chris Atherton's photo

Have you got around to playing with state management JS libraries other than Redux? How would you say they fare against Redux, or better what are a couple of things that a state management library other than Redux does better than Redux; and what are a couple of things that Redux does better than the counterparts?

Andrew Clark's photo

Front-end engineer at Facebook

Hi Chris! Please refer to the second part of my answer here: