An EntityAdapter implementation proposal #2402
Replies: 2 comments 1 reply
-
It seems to have not been taken seriously? I hope to implement this proposal. ❤️ |
Beta Was this translation helpful? Give feedback.
-
I've created a library for those interested in this proposal: https://github.com/michaeljota/zustand-entity-adapter. I hope it is ok to use Zustand in the name, I'm not very creative. This is the npm link: https://www.npmjs.com/package/zustand-entity-adapter. Although it says it's version 0.1.0, it is stable and I've added tests to cover the expected behavior I consider. So, this should be ready to be used in production, but I'm eager for your feedback to make further improvements. Thank you all! |
Beta Was this translation helpful? Give feedback.
-
Update: You can find an implementation of this proposal here: https://www.npmjs.com/package/zustand-entity-adapter. Thanks!
I want to propose an EntityAdapter implementation. An EntityAdapter is described by the ngrx and the Redux Toolkit teams as a set of prebuilt methods and selectors for efficiently performing CRUD operations on a normalized state structure for a single entity state collection.
On a high level, both implementations can be divided into three parts, the state, the actions, and the selectors, and both implementations merge those parts into one adapter. Neither of the current implementations can be ported directly to Zustand because both are heavily based on their respective libraries.
Considering all this, I propose implementing a similar behavior, with a similar interface, for Zustand.
The state
Zustand allows us to create a minimal state factory, and delegate an extra state addition to the implementer.
The initial state should have this shape:
And the simpler function we can create to return this shape is:
The actions
Zustand allows the actions to be defined in different ways, using a curried store definition, using
combine
, or placing the actions outside the store. Additionally, Zustand allows partial updates to thestore
. Using this, we can create functions interacting with the EntityState only.We can define the actions we need with this interface:
To define the factory, we will need three additional functions:
We can define these needs through an options interface.
Because the
idSelector
is an optional method, andsort
will be used to compare and not for the actual sorting, we need additional methods to provide a default selector, and to sort the entities.The store can be updated with a set of independent internal functions, that can be mixed and combined to allow the interaction needed from the action methods.
For example, we can use create a setOne function.
And use it to implement multiple actions.
We can define the actionsFactory like this:
The selectors
Although Zustand doesn't provide or enforce the usage of selectors, the EntityAdapter generates selectors to read the entities efficiently.
ngrx
andRedux Toolkit
have similar selectors, but the Redux Toolkit has an additional selector to query by id an entity. Because of this, my proposal for the selectors is to have this shape:Notice the
selectById
curried overload, with that we can use the selector if we know the id ahead like:Or use an ID inside the store, like:
To implement that interface we can create a factory like this:
The adapter creator
With all that, I want to propose the following entityAdapter creator:
The store creator
Additionally, I have developed an entity store creator. The implementation I propose can be called with multiple overloads, but it has the same base implementation:
I wrote a couple of posts on dev.to about this:
Zustand EntityAdapter - An EntityAdapter example for Zustand
Zustand EntityAdapter - A bookshelf example
And you can test the implementation in this StackBlitz project.
Zustand EntityAdapter Proposal
Beta Was this translation helpful? Give feedback.
All reactions