Reasons for Redux "boilerplate"

redux-boilerplate-thoughts.md

[9:24 PM] acemarke: the typical complaints are things like switch statements, having to touch multiple files for actions vs constants vs reducers, verbosity of updating nested fields in a reducer, etc
[9:31 PM] acemarke: most of the "ceremony" and "boilerplate" and Redux exists for one of two reasons
[9:32 PM] acemarke: either because it's effectively a prerequisite for Redux's main capabilities and selling points
[9:32 PM] acemarke: or because it's good software engineering practices
[9:32 PM] acemarke: for example:
[9:32 PM] acemarke: * actions and state should be serializable because that enables "time-travel debugging"
[9:33 PM] acemarke: * data should be immutable because you know you're not making accidental modifications, and because it allows very cheap shouldComponentUpdate checks with React
[9:34 PM] acemarke: * since action types need to be serializable, they should almost always be strings, because those are easier to read. And since you'll want to use them in both your reducers and wherever you dispatch the actions, you should really only define them once as constants, and import that definition wherever needed
[9:35 PM] acemarke: you can put Symbols or functions or class instances in your state, but time-traveling will break
[9:35 PM] acemarke: you can mutate data directly, but it will cause React-Redux to not update as it would otherwise
[9:36 PM] acemarke: you can use non-strings as "types", but it might be harder to read
[9:36 PM] acemarke: you can define action objects inline, but you'll probably be repeating yourself. Ditto for making AJAX calls
[9:38 PM] acemarke: you can import your store directly into a module and call store.dispatch(), but you've locked yourself into that one store implementation, and the rest of your code is now harder to test
[9:38 PM] acemarke: wow. This is a great rant. I should save this for later use :)
[9:39 PM] acemarke: so in response to the common complaints that I listed earlier
[9:40 PM] acemarke: if making immutable updates is too verbose (especially if you're using object spreads or Object.assign), there's lots of utility libs that will abstract that out, or even something like https://github.com/tommikaikkonen/redux-orm that abstracts handling relational data
[9:41 PM] acemarke: if you don't like switch statements, writing lookup tables mapping actions to reducers is very common
[9:41 PM] acemarke: if updating nested data is hard, find ways to flatten it
[9:42 PM] acemarke: if you don't like touching multiple files to add an action, you can use something like the "ducks" pattern to put actions+constants+reducers all in one file, or just write your action objects inline where you're dispatching