Basic Idea behind Redux

Hello everyone,
I spent almost 2 days in Redux study also create some sample apps, go through the examples from redux documentation etc but still I am unable to understand clearly whats going on in redux. Can anyone please give me the basic idea behind it ?

General idea is that you store the entire state of the app in one place. Then, when something happens (an Action) it will modify the state in a predictable way (pure function).


Instead of having state only on a component level you store basically all the states of all your components in a single big JS Object on a global level.


hi @klabauter and @energistic , can you please explain in more details ?

If you don’t understand Redux then you don’t need Redux. So build your app without Redux and start learning.

Then when you ever run into limitations you might know what you need to solve those, and then you might find Redux a good idea (there are many, Redux is just one concept) and you will understand what problems it solves.

And also, realistically, most apps don’t need Redux at all (and in my opinion they don’t need React, but then again, you will miss out on the super duper hipster React bandwagon).


I’m not quite sure how to address the multitude of confusions exemplified in your post.

First of all: “If you don’t understand Redux you don’t need Redux”? What the hell?

Secondly: If he doesn’t understand Redux how the hell is he supposed to know that Redux solves a problem he may or may not have?

But do address @divyanshu: Redux acts as an application wide store of data. One of the most important roles Redux plays is when it comes to cross-component communication. For example, you have three components on your page: A navigation bar to the side, a top bar with a menu and the content in the middle.

The menu in the top bar allows you to login but your navigation bar has to change along with the logged in user. You could achieve that with a master component which contains all three and passes along information and stuff. But that gets complicated as soon as you involve more components.

Which is where Redux comes into play: It basically acts as an intermediator and stores data in a store which is available to all components. Which means that your top bar can now say to Redux: “Hey, this user XYZ just logged in.” and in turn Redux can then say to all components: “Whoever is interested in this: User XYZ just logged in.”


Well, you have a problem or you don’t :slight_smile:

What I’m saying is, you may or may not have a disease. Find out first, then start taking the pill.

He’s been studying 2 days to figure out Redux, and he still doesn’t understand what it solves → He doesn’t understand what disease the pill cures, because he has never seen the disease. Ergo, he doesn’t need the pill.

So first figure out if you have the disease, then start figuring out the cure.

Listen, dude, you come across very condescending and frankly, your posts don’t help him very much.

Actually, MobX isn’t a alternative to Redux since it is not a state container. Redux solves an architectural design following Flux patterns, MobX is more an Observable pattern implementation.

I’m learning Redux now. It seems the concept is just about stuffing all the application state inside a JS Object for client storage and pealing off data need using UI events …

Wiring up UI events to “Action Creators” (a function) that broadcast that event (another object with type and payload) to “Reducers” (function with a switch statement that determines what application state objects to pass around based on that original UI event). Then “Containers” respond if they’re “connected” to that state.

Compared to Mini-mongo – it’s A LOT of boilerplate code for passing data around. But hey, it provides “options/flexibility” right? :wink:

And I’m new to Redux (few days), but It’s still not clear where in Redux you load your data from the server – my point, when I get around to learning how that works, I’m expecting even more boilerplate code to come.

Do you want to have the bike preassembled (mostly put together) or do you want to put it together by hand before you ride it? You have a lot more “options/flexibility” when you put it together by hand, and that’s always a good thing right? :slight_smile:

I for one would like the option to have the Redux bike preassembled – even if that forces me to use the bike only one way (only petal clockwise for example). Then If I can’t get the out of the box stuff to work for me, have the option to break out into bike customizations.

I don’t know anything about MobX @leocavalcante, so you say it helps wire up the Observable pattern and not a state container? On the repo: its headline: simple, scalable state management.

This might be helpful to some looking at MobX & Redux:

From the article:

MobX by Michel Weststrate is influenced by object-oriented programming, but also by reactive programming. It wraps your state into observables. Thus you have all the capabilities of Observable in your state. The data can have plain setters and getters, but the observable makes it possible to retrieve updates once the data changed. In Mobx your state is mutable.

Here’s a cool link:, from the repo: this project attempts to solve the same problems observable models, state atoms and Flux try to solve.

Flux/Redux is a beautiful design that solves problems in complex UI, if you plan on using it in a CRM or a bunch of forms/lists/some simple actions, you’re just using it wrongly.

I’d use Redux for a complex Chat, Some fancy product builder, A diagram builder, An online photoshop , etc

I get it, it’s natural to be defensive of something you’ve personally invested in – even if its not the best choice out there. :smile:

I’m just now learning Redux, and so far it does seem to solve problems of complex UI – yet so do other tech, afaik.

Also, I think it’s god awful ugly (a big switch statement?) and verbose (how many functions do I need to pass around an object again?) – NOT beautiful as you say! :wink:

I’ve built several Redux applications and Chrome extensions. Now I’m using Apollo Client for data and MobX for state management. I’m not going back to Redux (and I realize that’s what Apollo uses… but if it’s abstracted from me, I don’t care :slight_smile:).

My opinion is Redux gives real advantages for teams where no one is sure what the other person is doing. It forces your state changes to be explicit. Very explicit. But for the solo dev / or small team, I think it comes with a high development overhead.

MobX is basically a set of singletons describing your state. Each of my singleton stores has a getter function describing the state, e.g.

import UIState from ...
const { isSlideMenuOpen } = UIState.currentState;
//toggle slide

Then the UIState is simply a class with MobX helpers…

class UIState {
    constructor() {
       this.state = default_state
   get currentState() {
     return this.state
 @action toggleSlide(newState) {
   this.state.isSlideMenuOpen = newState;

Wrap your components with MobX’s observer function and it’ll do the rest.

I find the “magic” of MobX well worth the boilerplate trade off.

1 Like

Well, adding a cool description at you GitHub repository doesn’t automatically makes it what you are describing.
The main diference behind the ideais and the concept of a state manager is that the overall flow of control is not dictated by the caller, while in Redux you give your state to the store, so it can manage it, and can only mutate though actions, in MobX the state, that you are responsible to manage, is proxied making it observable.

Anyway, both techs really does an awesome work and this is just me being a boring person about software development terms. :grin: Also, using none of them isn’t a bad choice at all, you can still properly manage and observe state in “pure React” by your own without losing control.

I do personally enjoy Redux by the fact on how it makes my React component stateless (what makes tests and reusability easier), how the mutations to the state are properly concerned into one way only pure functions (making it easier to test and debug) and how the state in centralized into one single source of truth plain JavaScript object (making it way better serializable and transferable).


Nice write up.

And I agree with the other posters… if you’re able to manage state without libraries, do it. But when you start finding parent components with bloated state or two distant cousin components need the same state, MobX and Redux are two good solutions.


I regret that we used redux. For small and medium apps i’d recommend mobx before redux.

Maybe interesting. Dan Abramov is the author of Redux.