Historically a single connected root has been frowned upon. I'm not so sure it should still be feared now that you can use PureComponents and FSCs the whole way down. ShouldComponentUpdate calls are cheap in pure-town.
For me, it's not a matter of performance, but rather of convenience. If I have a deeply nested component that needs to dispatch an action or access a part of the global state, I don't want to have to pass that all the way down through every other component in the hierarchy. The grandparent of a "Like" button shouldn't need to know the details of how it's implemented with regards to the global state, but it's forced to if you pass everything via props.
The newly official Context API might change things here, since it will be much easier to pass state down to grandchildren. I’ve not been keeping up to date with the plans for what react-redux will do with the new API yet, could be interesting.
Action creators always felt like and unnecessary abstraction to me. To avoid the aforementioned problem, I passed down a message library, or action object that has all of the actions on it, and dispatch. It's all I need!
Sure, action creators are "unnecessary" - you can always declare action objects and action types directly inline:
this.props.dispatch({type : "INCREMENT"});
Nothing's ever _forced_ you to use action creators, or declare your type constants separately.
However, we encourage use of action creators as a good practice. See my blog post "Idiomatic Redux: Why Use Action Creators?" [0] for some reasons, as well as the related Redux FAQ entry [1].
I respect your opinion but found each of the arguments contained within weak or easily countered.
> 1 ... put the logic for creating that action in one place
This isn't so simple. You end up duping the action in at minimum 1 AC (often many ACs), and onboard the complexity of an unnecessary function, plus importing and connecting that function all over your app. A UNIQUE_ACTION_CONSTANT is an easy refactor, unlike action creators, which can cause a cascade of changes when reworking component structures.
> 3 ... larger logic that goes into preparing the action object,
This justies a function, not necessarily an AC.
> 4 ... lets the action creator worry about how to handle things
Smart components are already aware of the state system by means of connect. Further, in AC aware apps, you have a whole swath of extra imports to manage, more connect calls to manage, and a binding API to consider, which sometimes requires patterns and team agreement on their own. dispatch + messages does away with all of that, and is shown to be simple/effective as popularized in Elm and Reason.
> 5 ... testing
Kinda. I'll meet ya half way here. But stubbing disptach and/or component methods is also very cheap, and super simple to reason about.
I say this all in the spirit of collaboration and productive debate :)
