There are many different frameworks, which sooner or later raises the question for developers and frontend engineers : what is best to use for a given project, what to avoid, why a particular development environment might be necessary, and so on. Of course, there are many possible answers and plenty of information on this topic. In this article, we’ll try to explore the need for Redux, why it’s in demand, and what makes it special.

Some developers love it, others — not so much. But as many masters, as many opinions. Managing massive data flows and their connections was indeed tricky before Redux appeared. Inspired by Facebook’s Flux architecture, Redux was created to manage state in JavaScript applications. While it's mostly used with React, many web developers successfully use it with other frameworks and libraries like jQuery, Angular, or Vue.

With a very small footprint (around 2 KB including extensions), Redux ensures that every component in an application can have direct access to the app’s state — without the need to pass props down through child components or use callbacks to send data back up.

In this article, let’s look at how Redux is deeply rooted in functional programming concepts and how to determine whether a web developer should use it in their app or site interface.

When and Why Redux Is Needed

Common sense suggests there’s no need to start using a new framework with every project just because it's the latest shiny tool for various tasks. Don’t components already have their own state? So why would we need yet another state management tool?

Don’t get it wrong — React is powerful enough to be used on its own in many projects. We’ve already explored React in detail and showcased projects built using only this library to create UI functionality (essentially the entire app). However, as an application grows more complex with more components, relying solely on one framework to manage all the data and interactions can become difficult and overly complicated. You might face numerous issues, inconveniences, and excessive labor.

And this is where Redux can save time; it drastically reduces and simplifies the challenges that arise in large-scale applications. Developers experienced with React know its data flow: parent components pass props down to child components. In large apps with shared data, constantly changing and stored in a central place, it becomes hard to read and maintain the code — even for yourself.

To illustrate, let’s look at the diagram below.

In React (and other frameworks), it’s not recommended to create links between components that don’t have a parent-child relationship. React notes that if you do this, you’ll essentially create your own global event system — similar to Flux. That’s exactly where Redux comes in.

Redux gives us a store to hold all application states. If component A changes its state, this change is sent to the store. Then components B and C that need to know about the change in component A can retrieve that updated state from the store:

See? It’s even better than we thought. If our components were directly interacting with each other, we’d end up with a fragile, unreadable, error-prone codebase. Redux improves and restructures this situation.

Component A sends its state changes to the store. Then if components B and C need those updated values, they pull them from the store. This creates a seamless data flow logic.

Beyond its core mission, Redux brings many other advantages. Let’s look at three particularly important benefits:

With a single source of truth (the store), developers have fewer problems synchronizing the current component state (from the store) with user actions and other app parts.

Redux enforces strict code organization rules, which reasonably lead to more predictable results — making code easier to manage.

Working with Redux involves pure functions that are isolated from each other. This correlates with the golden rule of writing testable code: write small functions that do only one thing and remain independent.

Sounds great and simple. If your app is complex — use Redux and forget the rest. But is it always the case? What if there are scenarios when Redux isn’t actually needed?

When Redux May Not Be Needed

It may seem obvious to some readers, but we’ll say it anyway: you don’t always need Redux. Sometimes it makes more sense not to use it at all. If any of the following scenarios apply to your case, Redux is likely unnecessary:

If you’ve found your case here, Redux probably won’t be required. Regardless of the app type or site purpose — it depends on complexity and scale. But Redux, despite being just 2 KB in size, has some powerful capabilities.

Redux in Parts and Under the Microscope

Actions

These are just events, created using functions that send data from the application to the store. Data can be sent in various ways — via form submissions, API calls, or basic user interactions. Every Redux action has a type property describing the action type, and the “important” info sent to the store. Let’s look at a simple example of an action (actions.js) posted on GitHub.

To trigger an action anywhere in the app, Redux uses the dispatch() method, which sends actions to the Redux store indicating state changes (dispatch.js)

Reducers

Since Redux doesn’t allow apps to directly change component state stored in the store, it uses dispatch() for that. The dispatch() function only signals intent to change the state but doesn’t do it — that’s why reducers are needed.

Reducers are functions that read the app’s current state from the store via the action sent and return a new state. Here’s some code ( handle-auth.js ) showing how the current state is received and the next state is returned:

When building more complex apps, it's recommended to use combineReducers() — this method combines all reducers in the app into one list of functions ( index-reducer.js ). Each handles its own slice of app state and receives a unique state parameter.

It's worth noting that reducers should be written as pure functions, meaning:

Store

The store is like the heart of Redux. It’s the single source of truth containing the app’s entire state and offering access to it via a few methods, action dispatching, and registration. Any dispatched action returns a new state in the store through reducers. Here's the store code ( create-store.js )

Functional Programming and Redux

If you’ve already decided to use Redux, you should also understand how functional programming works. Redux is based on functional programming principles, and understanding them will give you a clearer view of how Redux works and why it’s effective. Without a grasp of the framework’s fundamentals, working with it will be tough — and this applies to any development environment.

So, what are these “functional programming” principles?

Functional programming involves writing simpler, smaller, isolated functions. This approach makes coding, testing, and debugging easier. Since the functions are small and isolated, they’re reusable and can be copy-pasted wherever needed.

It also helps avoid writing excessive code. But again, functional programming requires understanding concepts like pure functions, anonymous functions, closures, and first-class functions. And that’s just part of it.

Conclusion

It’s true: Redux is a powerful library for managing app state. And yes, it truly earned its popularity. What's especially interesting is that Redux is successfully used in projects like WordPress — just like RedBox found its way into Uber and Twitter. It’s also true that Redux isn’t suitable for every app.

Apps that perform mostly simple actions and don’t require server-side rendering likely don’t need Redux; component-level state management will suffice. But in any case, Redux is a great tool worth trying — especially for those who enjoy React and know how to use it.

Still, as always, some consider Redux outdated for data handling. But everyone has their preference, and facts remain facts.