| Appreciate the feedback. Could you give specific examples of what you mean by "arcane boilerplate" and "leaky abstractions"? We don't have any plans to change the actual API, but I would genuinely be interested in any suggestions or concerns you have with it. It's also worth noting that I personally highly recommend consistently writing separate action creator functions [0], and using the "object shorthand" argument to `connect` instead of writing a separate `mapDispatch` function. That said, it also seems like part of what you're concerned with is the fundamental design of Redux. The use of plain object actions as a layer of indirection is deliberate [1], and it's what enables capabilities like time-travel debugging. Actions need to be serializable for that to work, and therefore strings are the best solution for the action's `type` field [2]. You certainly don't have to keep _everything_ in Redux. You should consider whether a given bit of state should live in Redux, or in a component's state [3]. But, if you _are_ going to keep data in Redux, then actions and reducers are necessary for the Redux data flow. They don't have to be in separate files [4], but they need to exist to update the store. [0] http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why... [1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [2] https://redux.js.org/docs/faq/Actions.html#actions-string-co... [3] https://redux.js.org/docs/faq/OrganizingState.html#organizin... [4] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... |
I'm not being a grump either. I coded Perl professionally for over 5 years and am well-versed in terse, functional idioms, but the community rightfully decided that strings of punctuation were too obtuse for practical use.