Create read/write utility hook like React useState #40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I take it from #37 that a signature having the capabilities of
React.useState
to permit reading and writing of a value within Store state would be valuable.The useSelected hook easily permits retrieving any property from the state, but this doesn't assist with a setter definition, which is impossible to derive from a selector which is just a black-box function.
The natural primitive operation (at least until path support is introduced) is to use a key from one of the state's child properties which can define BOTH a selector and a setter.
In this MR, we introduce a
useStateProperty
hook, with a signature similar to useState, driven by a keyed property of the Store state. Draft implementation is here and tests are hereFor example this would display first
red
thenwhite
after the useEffect change of state has triggered a futher render...Alternative: Using createStorePartition()
It is not suitable to use createStorePartition as a backing implementation, even though this seems promising since you can pick an individual property, read it and write it using the partitioned
Store
read/write methods. That's because it comes with a lot of overhead (creates a whole store, with its own listener list, and irreversibly subscribes the store to the parent store).As summarised here the store-partitioning pattern is intended much more for single-responsibility and interface-segregation. It means components can consume a complete store interface (including watch) without knowing that it's actually a sub-part of a larger Store, and multiple subscribers can then benefit from the efficiency of having ALL their watch subscriptions eliminated by a single check (that their partition of the store hasn't changed).
These aren't requirements of the case described by #37
Also until the implementation of #36 the creation of store partitions can't be undone (there is no destroy that detaches watchers) meaning this kind of derived state is poorly managed as part of a React render and could lead to memory leaks.
Closes #37