feat: extend useStableO to support an optional Eq argument
#8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jleider
reviewed
Jan 20, 2023
| useStable(initState, E.getEq(Eq.eqStrict, Eq.eqStrict)); | ||
| export function useStableE<E, A>(initialState: Either<E, A>): StateTuple<Either<E, A>>; | ||
| export function useStableE<E, A>(initialState: Either<E, A>, leftEq: Eq<E>, rightEq: Eq<A>): StateTuple<Either<E, A>>; | ||
| export function useStableE<E, A>(initialState: Either<E, A>, leftEq?: Eq<E>, rightEq?: Eq<A>): StateTuple<Either<E, A>> { |
There was a problem hiding this comment.
Its possible with this signature that a user could provide a left but not a right Eq or vice versa if undefined is passed as a left. In that case this function does not behave as you would expect since its explicitly checking if both exist.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Currently users can only provide primitive values to
useStableO, which means it effectively doesn't support Options containing any non-primitive types.The current workaround is to use
useStableand manually wrap theEqinO.getEq. Handling this for users is the reasonuseStableOexists, so it seems counter-intuitive to have users drop down to a lower-level construct, especially since it's not immediately obvious that that combination is how we support this use case.It would be nice if
useStableOsupported this out of the box.This PR extends
useStableOto support this use case by adding an optional second argument touseStableO, which is the customEqthat, if provided, will be used to determine whether state should be updated.By having the argument default to
Eq.eqStrict, this new behavior is opt-in. Things will continue working as before for existing users, so a minor bump is all that's necessary.I can add tests and documentation if this is a change y'all think makes sense, and I'm happy to make whatever adjustments that are requested during review.
===
I also added
useStableRef, which works the same way asuseStable: settingref.currentwill only succeed when the values are different according to theEqthey provided. I think it probably makers sense for that to be in a separate PR, but I thought it would be useful to get feedback on the addition.