[ratww]

I don't know if I agree... I've used "traditional" Redux in very large projects and the boilerplate far from minimal, and it grows in the same scale the app grows. And it's in the parts that grow more, which is app code: action types and action creators are very un-DRY and repetitive. Switch statements are way noisier syntatically compared to other solutions such as classes or objects (used in VueX and RTK createSlice). Etc.

I think it speaks volumes when the Redux maintainers are going into a direction that uses less boilerplate, like Redux Toolkit.

Honestly, there's nothing wrong with boilerplate, but I guess it's time to admit that some people love it and others hate it.

[acemarke]

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] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...