Redux was built as an implementation of the Flux Architecture. In Flux, you have different "stores" for different types of data (such as a `UsersStore`, `PostsStore`, and `CommentsStore`). One of the key concepts of Redux is that instead of having separate stores for each type of data, you can have separate "reducer functions" that are responsible for initializing and updating those data sets, and write another function that combines all of them together into a single object state tree. So, the standard encouraged approach is that the root reducer function delegates the work of updating each "slice" in the state tree to smaller functions, and so on ad infinitum. That way, each individual slice reducer function can be written and understood in isolation.
My blog post "The Tao of Redux, Part 1 - Implementation and Intent" goes into a lot of detail on the history, design, and influences behind Redux [0], and Dan's post "You Might Not Need Redux" [1] talks about the tradeoffs that Redux asks you to make and the kinds of benefits you get in return.
My blog post "The Tao of Redux, Part 1 - Implementation and Intent" goes into a lot of detail on the history, design, and influences behind Redux [0], and Dan's post "You Might Not Need Redux" [1] talks about the tradeoffs that Redux asks you to make and the kinds of benefits you get in return.
[0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
[1] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...