"Too much magic" is a serious stretch. Running through the tutorial here: https://egghead.io/courses/getting-started-with-redux, you pretty much reimplement the whole thing. It's just not that much code. There's plenty of optimizations and edge-case handling in the production version, but overall there just isn't much.
> you lose the concept of independent components
How? Components take props. They're just as independent as they were previously.
> everybody is notified of the inner state of each component
This... isn't the case.
Redux (and Flux in general) is useful when there is application-level data that needs to be shared across different components, and otherwise something ends up being a prop to a bunch of things that shouldn't be. Or when you want something to remain around when components go out of scope. If you don't have this problem, Redux is overkill. For larger apps, it's damn useful.
It's not redux itself which has too much magic in it, just your application flow that becomes magic when using redux.
> How? Components take props. They're just as independent as they were previously.
But in raw react it's straitforward: props are properties passed in the jsx tag of the element. With redux your props just pop out of nowhere when some event is dispatched somewhere in your code and your (smart) component can also change any other component's state without you knowing it. I know this kind of behavior can be useful sometimes (because you exactly want to do that) but in many situation you don't need it (in the same app I mean).
My problem with redux is that it makes the remote control implicit instead of explicit. Plus you don't always control redux by yourself but are also encouraged to use a lot of librairies that tamper the global state behind your back: redux-router, redux-form, etc.
I don't think its really all that magical when looked at as a giant component. In the context of the react-redux lib, its really similar to just having one large top level component that contains your entire state and all methods you would want to commit (but instead its called a store and actions). Everything is still unidirectional in that it has to go through that main redux provider and then gets passed back down to all the children, without the need to pass around every single possible method to each child.
So even if you have two "smart" components they are still just children of that main redux provider and therefore it makes sense that they can impact each other. The same way children can call methods that change a parents state on normal react components.
The "container component" pattern is widely used throughout the React world - it's simply any component whose primary responsibility is retrieving some data, and passing that as props to children. Could be making an AJAX call in `componentDidMount`, or something else. In this case, the container components generated by `connect` simply manage a subscription to the Redux store, retrieve the current state when notified, and run your `mapState` and pass the result down. Absolutely no magic at all, and definitely not "also changing any component's state without you knowing it".
As for other libraries, they're still dispatching actions, which means that all updates to the store are traceable (especially if you're using the Redux DevTools).
The caveat here is that with flux/redux, I'd argue "make as few components as reasonably possible interact with redux" is a best practice. If "things popping out of nowhere" is a problem, you probably have too many components listening on your stores.
That was actually the early advice for how to use Redux, but experience has shown that leads to less than optimal performance. In fact, benchmarks show that _more_ connected components usually leads to better perf, as the cost of notifying more subscribers is less than the cost of more wasted re-renders.
> you lose the concept of independent components
How? Components take props. They're just as independent as they were previously.
> everybody is notified of the inner state of each component
This... isn't the case.
Redux (and Flux in general) is useful when there is application-level data that needs to be shared across different components, and otherwise something ends up being a prop to a bunch of things that shouldn't be. Or when you want something to remain around when components go out of scope. If you don't have this problem, Redux is overkill. For larger apps, it's damn useful.