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).
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().
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for your reply. I do have a prior (well, it's still actively maintained) library called
react-entitieswhich 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:
useContextthanuseState.useCallbackwhen invoking actions there.react-entitiesstandalone actions would be simpler (and more flexible).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().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.