Earlier quoted context omitted.
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 relat…
> 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 :)