Why you should NEVER use Redux with Angular

Last modified: August 7, 2019

Ask all your coding questions @ codequery.io

Preface: What is Redux?

Redux is a JavaScript library for managing application state. It was popularized by React because it solved the "extraneous props" issue and played well with flux architecture.

What is the extraneous props issue?

Like Angular, React generates UI components that fall within a “component hierarchy”. Parent components can pass data to child components by way of props. This is similar to how the @Input decorator works in Angular.

Check out this example to see how this works in React.

While this makes it possible for components to share data, it gets messy when you want to pass data 5-10 levels up or down the component tree. Components end up having “extraneous properties” that create unnecessary relationships with other components. This makes them less reusable.

What is Flux?

Flux is a design pattern popularized by React. It emphasizes unidirectional data flow and proved more performant than the two-way data binding popularized by AngularJS. In fact, the rewrite of Angular was largely influenced by Flux concepts. You can read more about Flux here.

Why You Should NOT Use Redux With Angular

While Redux solved a lot of problems with React, it’s use case doesn’t apply to Angular.

React is simply a UI component library. Angular is a highly opinionated framework around dependency injection (DI). This makes it easy to share state out of the box. Services can easily be shared across different component classes....

export class AppStore {
    userName: "Sam"
    constructor() { }
export class Comp1 {
          this.displayName = store.userName;
export class Comp2 {
          this.userName = store.userName;

While you can achieve something similar with React, the easier option is to use Redux.

This is why Redux became so popular with React. It's the same way other third party libraries (like Axios) became popular with React. These libraries are necessary because React is simply a UI component library.

Just like Redux makes it easier to share state, Axios makes it easier to make Ajax requests.

And just like Angular doesn't need Axios because of it's own httpClientModule, it doesn't need Redux because of things like DI, services, and RxJS....

RxJS and Redux

RxJS is a library for making async requests. It leverages the observable design pattern to bring a reactive pub/sub functionality to Angular.

Using RxJS, Angular components can subscribe to event streams. This allows them to listen for data changes (events) over time.

So what does this have to do with Redux? It turns out Redux implements a similar pub/sub relationship between components and the store. Components subscribe to stores in Redux just like components subscribe to RxJS Observables in Angular.

For these reasons, you can argue that Redux is a redundant addition to Angular because Angular achieves the same behavior using RxJS.

Too Much Boilerplate

Redux works by dispatching defined "actions" that functions called "reducers" interpret to update a centralized "store". This tends to generate a lot of boilerplate code as your app grows and gets messy fast.

While Angular has its fair share of boilerplate, you don't need an excuse to add even more. Since using things like RxJS and shared services is a proven alternative, there is no need to further complicate your code base with a bunch of actions and reducers.


The Angular team put a lot of thought into component interaction and shared state. The framework already has everything you need to share state across different components. It's change detection strategy is super fast out of the box so don't worry about performance implications of cross-component interaction or immutability and OnPush.

Remember that Redux was an answer to React problems. And just like Angular doesn't need Axios, it doesn't need Redux...


Jake Leveroni
September 5, 2019
I agree that redux was a solution built to solve react issues but conceptually it's just a state management tool which I think can apply to some angular applications. I haven't worked extensively with different angular redux flavors but I have worked a lot with ngrx. I completely agree that it adds an enormous amount of boilerplate code but in certain circumstances that boilerplate becomes a powerful framework of state management. In most applications state can and should be managed in services and alternative persistent storage etc. However in complex applications that rely on pulling from large data sources in real-time and share that data across the application I'd argue that a redux style store is incredibly beneficial. At some point with large applications, storing your state in services just becomes you rewriting the existing functionality of a redux style library. I get that dispatching actions for every little thing can become tedious but I think if you build your store thoughtfully it will benefit you in the end.
Alexander Joseph
September 2, 2019
Alexander Joseph
September 2, 2019

You might also like: