Thanks Fred.

Redux is all about state management in your application. It should be considered independent of how you render your views.
Angular does not have a great way to manage state across views (components).

Let’s say you have a page with 3 view components that are dependent on the same piece of data. In order to serve that you would like to load the data just once and save it in the memory somewhere and have the 3 components read from this saved state to display it. Now, let’s say 2 of these components can also modify the data or the data can be refreshed from the backend by another asynchronous process periodically.
In order accomodate this, you would need to cache this data in a single place so the consumers of the data can read/write from it. In Angular, you would typically create a service (as they are singletons) as a container for this data. In addition, you would need to manage conflicts when more than one component or service tries to update the data at the same time. Now imagine you need to scale the application and have large amount of data you need to manage with these disjoint/scattered services in your app. That becomes a nightmare to maintain, debug and scale over time, especially on larger teams.
Redux gives a well-defined pattern to manage state. It is a central and single source of all your shared data, so you know exactly where to look. It also defines a single way to update data (thru actions) so nothing is directly updating data, thereby avoiding conflicts.

There are alternate ways to manage state. One example is breeze. You could create your own if you’d like. For smaller apps, you might be able to get away, without having one, but I think it’s essential to have a standard way to manage your state in any single page application of significant size.

Thanks for following thru with this blog series and posting these Qs. Keep it coming.