Thanks for the comment Nikolas LeBlanc
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.
You’re saying: “just use setState”.
I love setState as well, but they have some problems:
- You won’t be able to have a stateless (functional) component
- You’ll use ‘this’
- This pattern doesn’t scale for complex projects
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.
In the projects that we’re using Redux Zero, we’re using lots and lots for GraphQL calls, and this wasn’t an issue here.