Redux Vs BehaviourSubject - whats the difference?

Question

Assuming you're an Angular dev you might have a service called User Service. This service has a behaviour subject (see rxjs) which your components subscribe to and lets say the service also has a few methods to change the user state.

your top level component listens to the user service state and inputs it to it's child component. That child component then calls a method on the service to change the user state and the behaviour subject emits a new value. Now your component listening gets an updated value and passes this down to its children.

Or in another implementation you have a bunch of components at the same level listening for state change. One calls a services method to change state and the state is emitted, all components listening get the new state.

Over on the Redux side I am very new but I understand that there is one state area. your components instead write to the state and listen to the state from there.

I dont see the difference? I know Redux also allows you to see what actions where actually called to change the state, whereas in the behaviour subject example they are completely decoupled and have no concept of why or how the state was changed - they just know what the state is now.

Can someone shed some light please?

Answer 1

I've encountered this question when I came across a very common use case: developing a loader/spinner that can be toggled from anywhere in my app.

I myself have raised a similar question: what exactly are the benefits of redux, especially when behavior subject handles my current need.

I recommend this article: https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/

The article mentions key times when a store should be used, and some benefits:

• When injecting up the component tree into components where it seems naturally out of scope. (using behaviorsubject avoids injection like this anyway)
• Performance, testability, tooling, predictability

It also mentions negatives of using a store like Redux:

• The store does solve the problem of component interaction, but it also creates the need for managing state in your application, which might otherwise not exist when using other solutions.

After watching all the videos, and reading all the words, I've decided Redux is great. I really want to use it. However, for my current use case of sharing the state of a single object holding only:

{ show: true } 

or

{ show: false } 

It clearly is not the correct choice to adopt an entire library to handle only this single state when rxjs/behaviorsubject does exactly what I need with very little overhead.

The phrase that really struck me in the article:

If you don't know whether you need Redux or not, you don't need Redux.

I think that is to say, Redux is here to solve a huge problem: data immutability across large data stores. If you don't have that problem... Redux is not needed by you yet. :)