In my experience what ends up happening is that for 85% of application functionality you end up using a library that "manages" the boilerplate for you. For exam

In my experience what ends up happening is that for 85% of application functionality you end up using a library that "manages" the boilerplate for you. For example, is you are writing an application that communicates with a REST API I use something like github.com/klis87/redux-saga-requests - and the store, actions, and reducers are taken care off in just a few lines and I get loading states, collections, and errors in return. For the other 15% you write your own reducers because you need some one-off functionality. I like this because I get to opt in to widely used and understood state management framework - I don't have to teach other engineers whats going on or how to debug the app, and next I have a tried and tested framework that doesn't get too unwieldily on complex components, like query builders. However, at the end of the day, the projects I've used Redux were all enterprise-y SaaS web apps with several bells and whistles. I can definitely see Redux being a chore on other applications that don't have a crazy scope.