Angular has built in dependency injection, recommends to use services to encapsulate state. Built-in services use RxJs for propagating changes by default, and following that pattern gets you very far. Especially for an enterprise app.
Hm, right, forgot about DI. Still, RxJS is the one thing many of my peers just cannot seem to grasp. So IMHO that's actually a minus.
I'd pick RxJs over Redux, naturally if a team should use whatever they're happy with.
RxJS is not a replacement for redux, in fact ngrx is a redux implementation based on RxJS and Angular. It brings everything, including effects with their own plugins and it is quite a pleasure to work with.
I'm aware, I'm saying that using (a few singleton) services for managing state plus RxJS to effectively propagate (state) changes into every other component/service provides a comfortable development workflow/mindset. (I find redux-like patterns unnecessarily complex.)
Yes that I completely true. However, not sure of you know @ngrx/entity but it solves 80% of all business logic I need in a clean way. An most of the time creating services I end up building exactly what the framework gives me
I think RxJs evolved from "Reactive Extensions for .NET" which was quite popular even 10 years ago. So the core idea is probably well understood by many .NET devs.