Support for custom equality function

It seems like the library is currently hardcoded to compare the value produced by the selector using Object.is

https://github.com/dai-shi/use-context-selector/blob/ba7476affc7cf198c9ed72c2f5db538b3998ac39/src/index.js#L82

Sometimes it may be useful to use a different equality comparison such as shallow equal when composing an object. The redux useSelector API has an extra optional parameter for this purpose, which can be used like

const selectedData = useSelector(selectorReturningObject, shallowEqual)

Would you consider supporting this in use-context-selector?

[dai-shi]

Hi, thanks for opening an issue. ~This might be controversial, but I have a strong belief that react community should prefer using useCallback to equalityFn. In the case of react-redux, it can’t be helped because it had to provide a clear migration path from the HoC API.~ ~I’m pretty convinced about this with the upcoming useMutableSource. v2 is already implemented in #12, and it requires useCallback. Supporting equalityFn with useMutableSource would be extra work, and I’m suspicious about how to clearly make the implementation Concurrent Mode safe.~

~That said, I’m eager to learn the use case that requires equalityFn and provide a workaround or even a util function. Do you have an example that we can discuss on?~

(I was stupid back then…)

[rhyek]

Hopefully this wrapper solution or something similar can be considered as the standard export of the package. I was really hoping to replace Redux with Context API for application state management, however while use-context-selector seemed promising in this endeavor, not being able to specify an equality function like you can in Redux is a deal-breaker.

The equality function option would be especially useful when replacing Redux with Context since you usually need to grab both values and methods (mutations) from your context object and so referential equality is a clear problem. With Redux you’re doubly covered in this regard, because instead of selecting mutations you dispatch them through a separate mechanism.

Having the wrapper function mentioned in the above comment as a work-around is great, but I’m unsure how stable the solution is.