5 ms·

Sure, action creators are "unnecessary" - you can always declare action objects and action types directly inline: this.props.dispatch({type : "INCREMENT"})

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]. [0] http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why-use-action-creators/ http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why... [1] https://redux.js.org/faq/code-structure#why-should-i-use-action-creators https://redux.js.org/faq/code-structure#why-should-i-use-act...

cdaringe 8y ago
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 :)

cdaringe 8y ago

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 :)