It's time to ditch Medium for good! 🌈⚡️

Introducing Devblog by Hashnode. Blog on your domain for FREE. Highly customizable and optimized for developers.

Learn more

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:

Ask a Question

68 discussions

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

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.

Reply to this…

Share your programming knowledge and learn from the best developers on Hashnode

Get started

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

Show all replies

Teams at Facebook can use whatever tech they want to use. Some internal projects use Redux. 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, 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.

Reply to this…

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 :-)

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

Reply to this…

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?

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.

Reply to this…

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

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):

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!

Reply to this…

Load more responses