Agreed. Until recently, my team was responsible for most of the official IBM Watson service demos, and we standardized on React for those and built up a nice library of react components[1]. None of them used Redux, though, because in general it just wasn't needed.
When we handed off responsibility of these demos to the individual service teams, we wrote up guidelines that specifically recommended React but not Redux - with the logic that if the demo is getting to a point where Redux is providing value, then it's probably too complex for a demo.
Our new project is a more involved web app that includes lots of state, shared across many different components, and we're making great use of Redux there.
One of the things I find hardest with redux is to make reusable components (across projects), as they have to be added to the state tree somewhere, and then connected. With nested components you may get implicit dependencies on where in the tree it should be. All this makes it very cumbersome.
So even though most of our apps use Redux, the reusable parts use setState as they then can be completely independent.
Yeah, that is a tradeoff - globalized state makes a lot of scenarios easier, but does make complete encapsulation and reusability harder.
Most of the third-party "Redux-connected component" libs I've seen provide a reducer that they expect to be added to the root of the state tree under a specific key name. Works, but it's not ideal. I've seen a few that let you provide a selector or key name when you initialize the library, so that the library is more flexible in how it's connected.
There's been a lot of discussion of various approaches for implementing fully encapsulated/reusable Redux-based React components in Sebastian Lorber's "Scalable Frontend with Elm or Redux" repo [0], and my links list has a section of additional articles on the topic of encapsulation with Redux [1]. My Redux addons catalog also has a large section for libraries that implement some form of per-component state or component encapsulation in Redux as well [2].
So, it's not impossible, but it does take work and there are tradeoffs either way.
Yea, our new project has a lot of 'container components' where there is a parent component that connects to redux (and react-i18next) gets all of the data & translated text, and then passes it to a child component that is just a regular stateless component that could be easily re-used (and tested!)
When we handed off responsibility of these demos to the individual service teams, we wrote up guidelines that specifically recommended React but not Redux - with the logic that if the demo is getting to a point where Redux is providing value, then it's probably too complex for a demo.
Our new project is a more involved web app that includes lots of state, shared across many different components, and we're making great use of Redux there.
[1]: https://watson-developer-cloud.github.io/react-components/