DEV Community


Discussion on: Can React state management get any simpler than this?

ncpa0cpl profile image
ncpa0cpl • Edited

It is very unclear that "increment" and "decrement" function are in any way related to the "count" state, I'd imagine maintaining code written with this library would not be a pleasant experience, especially if it was a code written by someone else.

A much better approach would be to have the "useEntity(counter)" return an object with "count", "increment" and "decrement" as its properties. This would make it much clearer, and if you want to have simple looking state variable and methods names you can just use ES6 destructuring syntax and you'd have it like this:

const { count, increment, decrement } = useEntity(counter);

arnelenero profile image
Arnel Enero Author • Edited

Thanks for your reply. I do have a prior (well, it's still actively maintained) library called react-entities which does package the actions inside the entities.

Based on many user feedback, I decided that for this new library I would try decoupling the actions from the entity for reasons such as:

  • it makes it easier to implement orchestrator actions that can update multiple entities in one go (as discussed in the documentation)
  • it makes the "use" hook syntax simpler (returns a single value, not a tuple or destructuring)... more like useContext than useState.
  • the actions are pretty much static, so we are avoiding needlessly having to include them in the deps array of useCallback when invoking actions there.
  • many popular state managers like React Redux also separate actions/dispatch from the state hook
  • ultimately, I was aiming for "simplest" and based on feedback from users of react-entities standalone actions would be simpler (and more flexible).
skyjur profile image

the actions are pretty much static, so we are avoiding needlessly having to include them in the deps array of useCallback when invoking actions there.

What you did in your example with "static" actions is global state singleton. It's a very bad example to teach. Many books talked about this. I suggest to revisit SOLID principles and try to apply them. All OOP concepts are very much applicable everywhere where there is state. And in UI there is a lot of state that needs to be managed.

Passing down dependencies is nothing wrong. It's the right way. When it's too much and interduces dependencies that we don't want to have - it can be avoided in React with useContext().

Thread Thread
arnelenero profile image
Arnel Enero Author • Edited

Just to be clear, this article is not intended to "teach" or even recommend certain "principles". It is merely to showcase—in the most succinct way possible—a library that some folks may choose to explore. And being designed exclusively to work with Hooks, it is obviously for those that prefer functional programming. There is never the intention to claim that it is the "best" approach, nor to compare with libraries, as the article has made clear.

As for the library itself, just like the over-simplified examples (not recommended patterns) used to demonstrate... it is not meant to challenge anybody's approach to development. It is unopinionated, and merely provides flexible building blocks that individuals can use while applying whatever programming principles they choose to adhere to.

Forem Open with the Forem app