Redux Vs BehaviourSubject - whats the difference?

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. :)

I have an Angular application implemented using behavior subjects in a global service for preserving and updating state which i observe for changes throughout my application.

The code is very legible, works perfectly without issue, accomplishes the goal and is easy to troubleshoot. 👍

With that said, I took the time to try and migrate to a redux/flux pattern with ngrx and while i get the concept and benefit of having a central and immutable store for state, it felt like i was creating a tremendous level of complexity throughout my application in-order to implement it properly and have since abandoned the library.

It was the need for having to integrate side effects with ngrx effects that really made it frustrating to work with. The code did not feel reliable and i was beginning to run into problems whereas multiple observable subscriptions began to crop up during runtime, not to mention, a whole assortment of other issues related to observing for changes, legibility and organization of my code.

At the end of the day, is the best not the enemy of the good?

Redux is an implementation of the Flux pattern. That means that the actions and reducers are a parts of the pattern as well as having a single source of truth providing immutable state. Using a service that provides a piece of immutable state is just a part of what redux (or other libs using the Flux pattern like ngRx) provide.

Something to note is that ngRx (a lib similar to redux made around observables for angular) uses BehaviorSubjects for the state (or store in ngRx terms). So using the BehaviorSubject is definitely part of it!

Something to note when using Subjects is to try to make them private and allow components to subscribe to them through a method returning the asObservable function on the Observable. It can save you from some headaches later :)

I have since realised that the intent is different. Using a behaviour subject is fine - the intent is to store some state and you might have the same state, or some amount of cross-over state, stored in many behaviour subjects across your app (you shouldnt but it might be valid).

The intent of redux is different. It offers an approach with a single source of truth as state is stored and mutated in only 1 place in the entire application. Data is also immutable. Because of these 2 factors it is possible to establish a robust consistent timeline regarding your data mutations as well as what events from what area of the system caused those mutations, and that has allowed clever people to write clever tools to debug your application by 'rewinding time'.

The other answers here are great but I feel that they deal with implementation details, like actions (obvious) and reducers (mutation functions) and the real takeaway is the the difference is subtle since it lies in the difference in intent between the flux pattern and the observer pattern.

The flux pattern is as described - data stores that you can observe on in an immutable single truth way. I believe you could say it is a compound pattern using the state pattern and the observer pattern.

The observer pattern is about decoupling code through listening for events - probably the same events - and running different areas of code with different single responsibilities to ensure decoupling. eg a user changes their username on a forum via a popup, all the posts they have made on the open page should update with their new name, and the username displayed in the top right of the website header should change. These are different areas of responsibility.