Support for custom equality function

[robeady]

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

use-context-selector/src/index.js

Line 82 in ba7476a

|| Object.is(ref.current.s, ref.current.f(nextValue))) {

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..)

[victorporof]

@dai-shi I'm not sure I follow. If a selector composes an object, using referential equality will always trigger a rerender. Shallow equality would help; how would useCallback help instead?

[lishine]

const selector = useCallback(s=>({a: s.a, b: s.b}),[])
const obj = useSelector(selector)

[victorporof]

@lishine The selector callback is cached, but it returns a new object every time. The selected value will always be different referentially.

[lishine]

Ok, my bad, it actually never triggers with the above code.
Then create this object in the useContextState with a useMemo. I mean where you create the state for the useSelector

[victorporof]

That would violate the rule of hooks, wouldn't it? Using "useMemo" in a selector means that it's called in function that is neither a component nor a custom hook.

I suppose the deeper underlying point is that you can memoize the returned object (not through useMemo, but something else like reselect or just rolling your own memoization), but that's just ultimately a roundabout way of doing custom equality checks.

[dai-shi]

@victorporof Sorry, I think I mixed the two points. Ref equality is almost default with useMutableSource (and React in general), so supporting equalityFn is an extra work that I think shouldn't be part of this library. So, one would need to use memoization library before passing. I'm not very familiar, but reselect can be used or there would be more alternatives.

(Requiring useCallback is a different story.)

[victorporof]

To be clear, this is the point myself (and I believe OP) are referring to: https://react-redux.js.org/api/hooks#equality-comparisons-and-updates

If this library choses to only support memoization instead of equality checks for the generated selector data, then sure. However, the useCallback discussion seems unrelated.

[dai-shi]

However, the useCallback discussion seems unrelated.

Right, that was my bad..

(It's just a bit related when one were to implement it.)

[lishine]

So, one would need to use memoization library before passing.

This is what I meant.
In the hook that you pass to the provider, wrap the object with useMemo.

[victorporof]

@lishine You can't useMemo inside a useCallback, or another function that isn't a hook or a function component.

[dai-shi]

@lishine Yeah. Note that useMemo can only be used in render, and often the case with a selector is not in render.

[lishine]

Sure in render , in the component that includes the provider.

[lishine]

I write a custom hook that creates the state. That state is passed to the provider.

[lishine]

I write a custom hook that creates the state. That state is passed to the provider.