Our new "Style Guide" docs page gives a recommendation to "model actions as 'events', not 'setters' [0], and there were two recent talks on this topic that go into a lot more detail [1] [2].
I don't think actions are what they're talking about, but reducers as setters vs reducers with more complex logic. I stumbled against the same thing last week, and rather than duplicating the logic in two reducers I settled on putting the logic in the action and turning both reducers into simple setters.
When you mentally model an action as a "setter", like `SET_PIZZAS_ORDERED`, the reducer usually has almost no logic and just blindly accepts whatever value was in the action. The work of calculating the value was done before the action was dispatched.
If you model actions conceptually as "events", the corollary is that the work of calculating the new state typically ends up in the reducer.
Again no, these are modeled as events around a thunk: dispatch START_SEARCH, -> ajax -> any necessary complex logic -> dispatch RESULTS_RECEIVED or QUERY_FAILED. Multiple reducers listen to the same events, acting as simple setters.
I don't think actions are what they're talking about, but reducers as setters vs reducers with more complex logic. I stumbled against the same thing last week, and rather than duplicating the logic in two reducers I settled on putting the logic in the action and turning both reducers into simple setters.