[the_gipsy]

It's too much boilerplate. In my current project, I have to describe one action 7 times:

  1. The constant var `const ACTION_NAME = ...`
  2. The constant's value `... = Symbol('ACTION_NAME')`
  3. The "action creator" function `const doAction = arg => ...` (extra creativity to add a verb here?)
  4. The action creator's return struct: `... => ({ type: ACTION_NAME, payload: arg })`
  5. The reducer switch clause `case ACTION NAME:`
  6. The container action to callback mapping `onClickThing: dispatch(doAction(42))`
  7: The jsx/component calling the callback `onClick={onClickThing}`

compare that to The Elm Architecture, from which redux is inspired AFAIK. An action only needs to be referenced in 3 places:

  1. The tag on the Msg type: `type Msg = ActionName arg | ...`
  2. The `case` pattern matcher in the update function
  3. The view sending said Msg/action

[pault]

It's just javascript... when I'm writing a redux-backed app I will often abstract out commonly repeated patterns in action creators and reducers. Every project is different so I just wait until things start looking predictable and refactor. Not trying to be snarky, I just see this a lot at work; people seem to be locked in to the patterns used in the redux documentation and never attempt to rewrite it as they would any other part of their app. It's quite simple (especially if you are using ES6 with its destructuring assignment) to write a function that takes an action type and a function body that eliminates most of the boilerplate.

[the_gipsy]

Actually, I agree with you and appreciate that redux doesn't force something like a framework on you. You have choice of (non-)immutability, async handling, organizing your code, or how to "wrap it up" like you suggest.