Appreciate the effort, nice and simple for sure, but a couple things that give me pause:
Nikolas LeBlanc
1071

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.

I agreed with you. That’s why we’re already discussing what’s the best way to solve this problem.

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.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.