I think it's important to distinguish between the "inherent" complexity" and "incidental" complexity in using Redux [0]. Dispatching actions and writing reduc

I think it's important to distinguish between the "inherent" complexity" and "incidental" complexity in using Redux [0]. Dispatching actions and writing reducers is _inherent_ complexity. It's part of Redux's design, and is a deliberate level of indirection. Having to write nested spread operators to perform immutable updates, switch statements in reducers, and `const ADD_TODO = "ADD_TODO"` is _incidental_ complexity. Nothing about Redux's core design _requires_ you to write the code that way. There's valid reasons why those patterns exist [1], but writing a reducer with a switch statement vs a lookup table doesn't change how the Redux data flow behaves. My goal is to eliminate the incidental complexity, because it's not necessary and does present a barrier to people learning and using Redux. [0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/#dealing-with-complexity https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...