Managing State in Angular 2 - St Louis Angular Lunch - Kyle Cordes - Oct 2016
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about Redux or ngrx, state management and component-based architecture in Angular.
Recommended by 3 people across 2 different months, 2017 to 2019.
What it is
A 46-minute conference-style talk from the St. Louis Angular Lunch in which Kyle Cordes walks through six stages of managing state in Angular 2 applications, from small examples to large real-world systems. It ends with the approach he recommends, which builds on RxJS and a Redux-style store.
What people said
Strong rec Lidor Avitan · 2017-08 · Stack Overflow · on “State management concept vs other solutions”
I think you have to think more in terms of MVC vs CBA(component based architecture) rather than Redux vs MVC. Redux helps you synchronize state between your components and really shines when you got complex component trees that share state. I would like to point you to this excellent presentation that may help you understand the benefits of using Redux in a component based architecture. Managing State in Angular 2 - St Louis Angular Lunch - Kyle Cordes [this video]
Strong rec user5467273 · 2017-08 · Stack Overflow · on “How is Flux Architecture better than MVC”
I think you have to think more in terms of MVC vs CBA(component based architecture) rather than Redux vs MVC. Redux helps you synchronize state between your components and really shines when you got complex component trees that share state. I would like to point you to this excellent presentation that may help you understand the benefits of using Redux in a component based architecture. Managing State in Angular 2 - St Louis Angular Lunch - Kyle Cordes [this video]
Recommends Kiril1512 · 2019-08 · Stack Overflow · on “Angular with ngrx store, synchronize backend data (design choice)”
There is a trade-off: You could avoid both RxJS and Store, but this is impractical and unrealistic for building any Angular application at scale. You will end up working much harder in writing lots of code to avoid these things. And probably sacrificing some degree of correctness along the way. You can skip Store and go quite a long way with extensive use of RxJS for data flow. This really works very well. As an application grows though, if you are only using homegrown RxJS base data flow for an application, eventually you probably find you are gradually reinventing aspects of Store / Redux. This video is 46 minutes long but can help you: [this video]
Cites Vi Elite · 2017-07 · Stack Overflow · on “NGRX and state management for child components”
This is much depends on your use-case for each Component whether how many @Output and @Input they have. I have been using your 1st-approach for quite a time and it seems to be fine if your Child / lower-order component does very simple interaction ( take data top-down , then emit an Event back to Parent ) or a Dumb Component ( only takes Input ) . Sure that my Container was very big But if one of your Child components ended up having many I/O and having many other child-child components which also having the same, you might want to treat them as a Big-Child ( @Output() from Child will stay in Big-Child component instead of passed to GrandParent component ) Having too much @Output() from bott