Why Redux?

By the end of this blog you will understand what Redux is for, when to add it to your own app.

<

 Why should we use Redux at all?

The answer is not because - everyone else on the internet is using it. But, the reason is that it solves a problem – a very big problem.  The problem it solves is not app state management. React already does state management for you. Redux helps in state management, but that is not the problem it solves- It’s About Data flow…

React props provides one-way data flow. Props are used to pass data down the component tree.

Function callbacks are needed to flow data from child component to parent component. This callback function must be passed down to child component that want to pass data up.

Application state data are like electricity, connected by colored wires to the components that interest in it. Data flows down and up through these wires (props and callback).

So far so good!

Our application is growing and sooner or later you run into a situation where a top-level container component has some application data, and a child 5-6 level down needs that data. Getting the data down is like threading a needle. Anyway, It’s a pain!

Intermediate components in the line must accept and pass along the props that they don’t care about. This situation has name –  prop drilling. This means refactoring and reusing components from that line will be harder than it needs to be. In short, it’s not a good software design.

Would not it be dreamy if the component that did not need the data didn’t have to see that at all?

-          This is the problem – Redux solves. It gives component direct access to data they need.

-          It makes debugging easier – Redux DevTools let you inspect every single state change.

-          Time travel debugging – you can rollback state changes and see how your app looked in past.

-          More than that, it makes your code more maintainable in the long run and it follows functional programming.

<

Real life situation where you want to bring in redux-

Assume we are building a web conference WebApp like Adobe Connect. We have a chat pod which shows all the chat content and type of chat (public/private). We manage these state with local component state in the ChatArea component. Then we go to implement the NavBar component which shows chat notifications and number of lines in the chat. We quickly realized not only that we already have this data managed and rendered in the ChatArea component, but also, we want both the ChatArea component and NavBar Component to stay in sync as the chat content is received and user is not on the chat pod. In other word, we have two desperate components that need to read and possibly update the same state data.

This is the perfect time to pull ChatArea state out of ChatArea component up into Redux. Once this data is in Redux, the ChatArea and NavBar component can individually connect to Redux store and dispatch the function they need.

We can assume that our web conference web application has bunch of other react-based functionality all of which at this point is managed in local component state. Leave it as is!  We want to start thinking about a more managed solution, like Redux, is when that state is global. Most of our state probably isn’t global though. Which brings us to an important take away: we can and should use both local and global state in our apps. Managing everything in Redux is overkill. It may have negative performance implications.