Appreciate the effort, nice and simple for sure, but a couple things that give me pause:
- Now your actions are doing the work, so they’re not really actions at all, just functions being called by the component that will directly modify the state — as such, it’s more like you’ve created a store that can be acted on directly by a component without actions and without reducers.
- Testing will be difficult: You’re affecting the state directly via a side effect.
- No middleware: If there’s no dispatcher and no reducers, there’s no way to introduce middleware. Middleware is key in ensuring that your code remains declarative rather than imperative. In your example, we’d be doing async work from within the component’s “action”, and then setting the state once the async work is finished. This just looks more and more like what the redux ecosystem and middleware like redux-saga, redux-observable, or even redux-thunk were created to help prevent.
- No redux dev tools: without middleware there’s no redux dev tools.
I think ultimately, this may be a “baby out with the bathwater” scenario. In the interest of not having to write reducers or use a dispatcher, you’re starving yourself of what makes redux actually worthwhile. More boilerplate doesn’t have to result in a more difficult developer experience.