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)

James Clarke's photo

Hi Andrew! Glad that you are doing an AMA here. :)

What was the initial motivation behind building Redux? What were state management problems you faced that led to Redux.

Show all replies
Dan Abramov's photo

Terrific answer by Andrew. I'd just add he's being humble, and middleware was mostly his design. I was just merging whatever PRs he was sending because I was busy trying to get my conf talk demo working :P.

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

https://github.com/reactjs/redux/issues/6 https://github.com/reactjs/redux/pull/195 https://github.com/reactjs/redux/issues/113

Fox Hound's photo

Hey guys, I was always wondering - has Facebook.com adopted Redux at all?

Show all replies
Dan Abramov's photo

Teams at Facebook can use whatever tech they want to use. Some internal projects use Redux. I think some parts of Facebook.com website also started to use it but those are subject to change because sometimes people want to customize it for their needs, or might replace that version of the product code with something else altogether. Don't forget Redux is super tiny so adding or removing it is not a huge deal.

Nick Luparev's photo

Hello Andrew.

How would you recommend to learn Redux for someone who has small amount of experience in Functional Programming?

I comfortable with React and now I want to use Redux with it, because approach I currently apply uses events to notify React components when my models have changed, kinda like Pub/Sub bus. What I've noticed this approach doesn't scale very well and it's hard to reason about code when code base becomes bigger. I've read few articles about Redux and I think it can help me.

I have a lot of experience with OOP code. I worked with Ruby/Rails and focused a lot on good object oriented design.

I don't have a lot of experience with functional programming in general. I have some experience with Scheme, mostly for learning recursion.

I kinda understand lambda calculus and ideas behind it, I even wrote Applicative Y-Combinator using things like Tennent's Correspondence Principle and so on.

Also I have some experience with Haskell. I know what "Currying" and "Partially applied function" concepts mean and what they for.

For me it looks like that Redux is heavily based on ideas from Functional Programming.

I think my question consists from 2 parts:

What learning path would you recommend in order to be comfortable with ideas on which Redux based on?

What knowledge/skills should I have in order to be really comfortable working with Redux and build applications using it?

I know I wrote a lot here, but I think it will help you give me more specific advice using provided information.

If you thinking that there is some programming language where some particular ideas expressed better, feel free to mention it. I've found that sometimes it's very beneficial to get to roots of some idea (yes, I do have a lot of free time). For example learning Smalltalk made me a better Ruby developer and OO developer in general.

Thank you a lot for any suggestion/advice :-)

Andrew Clark's photo

Front-end engineer at Facebook

You definitely don't need to know lambda calculus to learn Redux. Or Haskell, or Scheme, or the difference between currying and partial application :)

In fact, one of the virtues of Redux is that it serves as a nice introduction to functional-lite programming, utilizing concepts like immutability, pure functions, and unidirectional flow. Since you already know React, it should be even easier for you to pick up Redux. (I always caution people against learning both at the same time. You've gone about it the right way.)

Once you learn Redux, learning those other concepts will become all the easier. As an example, neither Dan nor I really understood Elm until after we had come up with Redux!

EDIT: to answer your final question, Elm is a great first FP language, and a perfect stepping stone once you've mastered Redux

Jon's photo

The first time I saw Redux I thought it's a Elm clone in JavaScript. But the more I read about it, the more I found it derived. What are the differences in design solutions between Redux and Elm?

Andrew Clark's photo

Front-end engineer at Facebook

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 (perhaps our unfamiliarity with its ML syntax) 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.

The biggest difference is that the Elm Architecture is fractal. An Elm model's structure mirrors the structure of the UI, via composition. In other words, most Elm update functions (reducers, in Redux parlance) have a corresponding view.

Redux also uses reducer composition, but its composition does not mirror the composition of React components. In fact, we typically recommend that Redux reducers do not correspond directly to components. Those types of reducers are usually best implemented using local state.

Gytis Šk.'s photo

Hello Andrew!

Redux API is pretty much stable right now - I was wondering:

  • Is there is anything left to improve or add to Redux?
  • Can we except some new features in the future?
  • What do you think will be next thing after Redux (for state/app management)?
Show all replies
Andrew Clark's photo

Front-end engineer at Facebook

Dan responded as I was typing my response. Happily we touched on many of the same points!


The not-so-secret thing about Redux is that, while the larger community has been and remains incredibly active, the core Redux library itself hasn't changed much at all since last summer. In my view, Redux is essentially complete. Most of the innovation around it will continue to come in the form of third-party extensions, including projects like Redux Saga and Redux Observable. 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; however, I think it'd be great if the wide ecosystem of existing Redux middleware and enhancers could be scoped to work for an individual component. We're actually pretty close to making this happen. I believe this PR is the only real blocker (related to the INIT action): https://github.com/reactjs/redux/pull/1702

The next thing for state management? Well first, I'd like for people to stop putting everything into their Redux store unnecessarily. I like to imagine the different types of application state as a spectrum. On one end is highly local state, things like animations or form input values. On the other end is cached representations of external data, e.g. fetched via GraphQL or REST. In the middle is state that doesn't necessarily correspond to a specific component's lifecycle, or is shared across multiple parts of an app. This middle bit is where Redux really excels. For local state, I'm excited about ways to make React component state more functional. MobX seems to be doing some good work here, though I must confess that I haven't used it extensively. On the other end, for managing external data, I'm extremely bullish on declarative data fetching solutions, especially Relay which I think is just fantastic. I encourage you to check out Relay if you haven't already!

Jacob's photo

When did you start realising that Redux was gaining popularity, and being used in production level apps? What were your feelings? What would be your advice for an open source aspirant?

Show all replies
Andrew Clark's photo

Front-end engineer at Facebook

I knew Redux would be popular pretty much the moment I saw Dan's original version. I had a semi-popular (at the time) Flux library called Flummox, so it would have been easy for me to be stubborn and deny the obvious benefits of a reducer-based Flux. In one of my proudest moments, I instead quickly deprecated Flummox and jumped on the Redux train. Zero regrets. I caught some flak for this (reasonably—I could have done a better job transitioning Flummox users to Redux) but it ended up being a great decision, both for me personally and for the Redux community as a whole.

So my open source advice is this: you are not competing against other libraries. Well, I mean, you are, but if you focus mostly on "beating" the other guys and gals, you're eventually going to fail. Work on finding the best solutions, regardless of whether that's by collaborating on someone else's project or starting your own.

Nick Luparev's photo

Hi Andrew.

I'm going to start using Redux with React and in the process I want to understand how React/Redux and ideas from functional programming fit together.

Would it be better to work with Elm first and then after I've understand big picture shifted back to React/Redux?

Andrew Clark's photo

Front-end engineer at Facebook

I recommend learning Elm to pretty much every front-end developer. It's great that FP-style patterns in JavaScript have become more popular, and I'm absolutely thrilled that Redux has played a part in it, but there's only so much FP you can do in JS given the limitations of a language. Elm is an ML-style, purely functional language, so you'll get to learn things like pattern matching, algebraic types, and "immutability everywhere" that aren't possible with JavaScript.

Whether you learn Redux or Elm first probably varies from person to person. Dan and I both didn't really understand Elm until after we had created Redux and "accidentally" (subconsciously?) borrowed some of its ideas. We've heard from other people who report the same. So if learning Elm is overwhelming, give Redux a try and go back to Elm later to get the full experience.

Denny Trebbin's photo

Hi Andrew, You've got hired by Facebook just recently, Congratz! What are your responsibilities and how is Redux affected if its affected at all.

Andrew Clark's photo

Front-end engineer at Facebook

I'm only in my third week so I'm still in Bootcamp. (Bootcamp is Facebook's onboarding program for new engineers. It typically takes about 6-8 weeks, and it's used to both familiarize yourself with Facebook's product and engineering practices, and also to help you figure out what team you want to join.) Once I'm done with Bootcamp, I'll be joining the React team—which is exciting for many reasons, including that I'll be on the same team as Dan!

I doubt Redux will be be affected. However, one of the negative consequences of Redux's phenomenal success has been a trend away from using React's component state. There's a common misconception that using component state is bad or an anti-pattern because it's not as pure or functional as a Redux reducer. But not everything belongs in a global Redux store, and local component state is often the more appropriate place for many kinds of state in your app. I believe what people are really responding to is the awkwardness of the setState API, which has some edge cases and quirks that can be confusing. (See this Twitter thread for an example: https://twitter.com/acdlite/status/778268473772285952) The React team is interested in exploring ways to make the state API more functional and "Redux-y."

Jonathan's photo

Hi Dan, you often say that the Redux is inspired by a few core ideas in Elm; could you give a brief on what parts of Redux were inspired by Elm?

Dan Abramov's photo

I would say that some aspects of Redux are similar to Elm Architecture (https://guide.elm-lang.org/architecture/). 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. The differences between React composition model and Redux also contribute to React/Redux being less cohesive as a whole than Elm Architecture. As for historical context, neither me nor Andrew fully understood Elm Architecture when we were working on Redux, and only realised the similarities post factum. Nevertheless we're happy to direct people interested in such patterns to Elm which is worked on by smarter people than us.

James Clarke's photo

Thanks for the detailed answer to my last question! Do you think complex apps can be built without a state management solution like Redux?

Andrew Clark's photo

Front-end engineer at Facebook

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.

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. https://github.com/petehunt/react-howto is a good guide. https://github.com/facebookincubator/create-react-app 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.

http://reactivex.io/documentation/operators/images/flatMap.c.png

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 https://hashnode.com/ama/with-redux-cisteui6p005gzx53fstg8t6l#cistfv5e800bgz653fqb5qei2. 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: https://hashnode.com/ama/with-redux-cisteui6p005gzx53fstg8t6l#cit42ram00az60h53ikyfjlfd

Jonathan's photo

Is it okay to have component wise state when using Redux as a store management? Have you guys come across any cases when there is a need for this?

Show all replies
Andrew Clark's photo

Front-end engineer at Facebook

Oh yeah, Dan's right, I misinterpreted your question. You should absolutely use component state when it's appropriate :)

Henry Dineen's photo

Hey Andrew and Dan!

I was wondering what the relationship between ImmutableJS and React/Flux is like at facebook since they are both developed in house. I feel like ImmutableJS is a little overused sometimes but I was wondering to get some insight into how it is used at facebook and when you think it is appropriate for a Flux or Redux app

Thanks!

Show all replies
Dan Abramov's photo

I would add that Immutable also has its own pitfalls. Like when people hope it improves performance but call toJS() before rendering which completely defeats its purpose, as toJS() allocates a ton of objects with different identities every time. Or when people try to set fields on Immutable objects, or try to use it with the spread operator.

I would say that if plain objects and arrays work well for you, stick with them. Don't use Immutable just because somebody else does. If you want to introduce it for performance, make sure to measure your changes so that you don't regress by using it incorrectly.

Harry Vijay's photo

In terms of Routing, what do you recommend? Many developers while getting started with React/Redux tend to use react-router. What routing solution do you use in your own projects?

Show all replies
Andrew Clark's photo

Front-end engineer at Facebook

I use React Router. I've had quibbles about some of its API decisions in the past, but on the whole it has served me very well. I'm really excited about the upcoming API in version 4!

In my view, routing isn't a central piece of most React apps, so I wouldn't worry too much about whether your particular routing solution is the absolute best one out there. I will say, though, that the React Router team is smart, hard-working, and committed to solving the community's real world problems.

Kai Austral's photo

How would you answer when someone asks whether to use Redux or a bare minimum Flux implementation?

Andrew Clark's photo

Front-end engineer at Facebook

I would ask them what they mean by "bare Flux." Is "bare Flux" where you write an entire Flux library yourself, or is it where you use Facebook's Flux dispatcher?

David Chang's photo

I used Redux a bit about a year ago and haven't looked at it again until very recently. I'm wondering if there are any Redux specific tools/middleware in the ecosystem that you see others commonly using together? Any that you don't mind endorsing?

I remember using reselect, redux-logger, and redux-thunk..

Show all replies
Andrew Clark's photo

Front-end engineer at Facebook

Agree with Dan! While I haven't personally used Redux Observable or Redux Saga in a large app, I think they're an amazing realization of the vision we had for middleware last summer. The reason the middleware API exists in the first place is because we explicitly did not want to prescribe a particular solution for async. Redux Thunk is promoted in the docs because it's the absolute bare minimum solution. We were confident that the community would come up with something different and/or better. We were right!

Lorefnon's photo

Hi Andrew!

I have two fundamental questions:

[1] What is your favourite approach for managing routing - do you recommend coupling routing with the layout similar to ember router or react-router or would you recommend for a minimal router that just intercepts history change and updates the state tree and lets the components handle the rest of the logic.

The context is a portal like application having routes in the order of a hundred.

[2] Do you have any high level recommendations for structuring the state tree ? While it is understandable that it should be as normalized as possible, I am more concerned about information that denotes the current state of the application. Does it make sense to have a subtree that identifies what is currently relevant to the application ?

Alireza's photo

Hi, can I learn React after Redux?

Andrew Clark's photo

Front-end engineer at Facebook

Hi! I would recommend the opposite: 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.

Priyanka Malviya's photo

Hi Dan, I started learning ReactJS and now feel comfortable with the library. I know meteor fundamentals too. But I am facing a wall trying to create event based transitions from one component to another in SPA. Is redux the answer ? I know nothing about it yet. If yes, what are the best resources to learn?

Dan Abramov's photo

Hi! I’m not quite sure what you mean by transitions.

If you mean rendering a different component when an event fires (e.g. user clicks a button), normally you would call setState() from the button’s event handler, and render something else. Here is an example: https://jsfiddle.net/uokq5ggq/. Thinking in React is a good guide explaining how state works in React.

If you mean animations, I suggest to check out React Motion as well as watching this talk.

Rick's photo

Hey Dan,

Fancy to see you here. Here's a question apart from Redux. What is your work like in the React core team?

Dan Abramov's photo

My dream job. (No, seriously, it was my dream since about maybe two years ago, before I sent the first PR.)

In terms of what it's actually like, our work is generally pretty visible. Lately I've been working on Create React App because a lot of people in the community are frustrated by complicated tooling. I also send some PRs with improvements and bugfixes to React. For example I added a Chrome Timeline integration to the performance tooling that will be out in 15.4.0.

I live in London so I talk to the team once a week via a conference call to sync up on tasks and priorities. I try to publish our meeting notes on https://github.com/reactjs/core-notes.

littlepsylo's photo

Hi Andrew and Dan :)

First, thanks for your awesome works !

What's the coolest thing you've made with redux ?

Gael du Plessix's photo

Hi folks !

I'm building my first App with React+Redux and I fear I'm doing an anti-pattern. I use a middleware to perform my network requests (something like this https://github.com/agraboso/redux-api-middleware). So whenever I need to perform a request, I have to dispatch an action. Thus, I feel like my actions become just like regular functions, I may dispatch them even if I don't really need to update the state. Does this look like an anti-pattern, or does dispatching actions for basically any tasks make sense ?

Thanks ! :)

Dan Abramov's photo

First of all, 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 ;-)

As for your specific question, it depends. If most of my network requests don’t end up as useful actions changing the state, I wouldn’t use middleware for them, and just do them directly. However if most of them change the state, but a few don’t, I might use middleware for consistency. Don’t worry about “anti-patterns” and use your best judgement.

ahmed-abdelkarim's photo

Hi i was asking if it is a vaild pattren write a reusable reducer this way

`` const INC ='INC'

const counterReducer = (id, initialState) => (state = initialState, action) => {

if (action && action.meta.id === id) { switch (action.type) { case INC: return state+1 default: return state; } } else { return state; } };

const store = createStore(combineReducers({ c1:counterReducer("c1",0), c2:counterReducer("c2",1), c3:counterReducer("c3",2) }));

// dispatch action to first reducer// store.dispatch({type:INC,meta:{id:"c1"}});

// dispatch action to second reducer// store.dispatch({type:INC,meta:{id:"c2"}});

// dispatch action to second reducer//` store.dispatch({type:INC,meta:{id:"c3"}}); ```