Allow passing a default equality function to createSelectorHook

[ghost]

New Features

Allow passing a default equality function to createSelectorHook

What is the new or updated feature that you are suggesting?

I'd like to suggest adding a second argument to createSelectorHook to overwrite the default equality function.

Why should this feature be included?

My redux store consists for the most part out of custom classes from a functional programming library. This library, prelude-ts, relies on hash codes and an internal .equals() function on its objects to check equality between objects that do not share a reference:

const a = Vector.of(1, 2, 3);
const b = Vector.of(1, 2, 3);

console.log(a === b) // False
console.log(a.equals(b)) // True

I assume other functional programming languages do something similar, and even outside of an FP context, this seems like a moderately frequent use-case to me in a language that does not support operator overloading.

To ensure I don't rerender my components unnecessarily, I pass my own equality function for now:

// helpers.ts
const preludeEq = (a: HasEquals, b: any): boolean => a.equals(b);

// In some component:
import { useSelector } from 'react-redux';
import { preludeEq } from '../helpers';

const ProjectList = () => {
  const projects: Vector<string> = useSelector(store => store.project, preludeEq);

  return (
    <ul>
      {projects.map((name) => <li>{name}</li>)}
    </ul>
  );
}

I would like to instead be able to create my own useSelector hook and pass preludeEq as a default equality function. Something like:

// helpers.ts
const preludeEq = (a: HasEquals, b: any): boolean => a.equals(b);

// store.ts
import { preludeEq } from '../helpers';

export const useSelector = createSelectorHook(null, preludeEq);

// In some component:
import { useSelector } from "../store";

const ProjectList = () => {
  const projects: Vector<string> = useSelector(store => store.project);

  return (
    <ul>
      {projects.map((name) => <li>{name}</li>)}
    </ul>
  );
}

What docs changes are needed to explain this?

createSelectorHook actually doesn't seem to be referenced in the docs, but this might touch upon:

• Docs: Add hooks usage guide page #1575
• Docs: Rewrite tutorial to show hooks as the primary API #1574
• [Docs]: improve usage of second arg of useSelector (equality function) #1504

I'm more than willing to submit a pull request for this :) Since the first argument to createReactHook is optional, this change could be fully backward compatible.

[markerikson]

On the one hand, I could see this easily being done in userland in much the same way we suggest creating a useAppDispatch that adds a known type signature.

On the other hand, I don't really see a reason why we shouldn't do this.

So sure, if you'd like to submit a PR, we can probably get that one. Would also be great if you could throw in some additional docs info on the custom hook creation as well while you're at it :)

[ghost]

Awesome, I'll get on it somewhere soon. As for the docs, could you outline the use case for passing your own Context? I don't immediately see it myself.

[markerikson]

@veramone the only real use case for that is if you want to use multiple Redux stores within a single React component tree, so you need sections of the component tree to use store B instead of store A. Both connect and useSelector rely on accessing the Redux store instance via context, and the default behavior is to use the singleton ReactReduxContext instance we create internally. You could actually render <Provider store={storeB}> for a particular subtree and override the default context value for that section, but if you want to intermingle them or something, you'd have to mix contexts.

[antonobergklarna]

I think createUseSelector should take an object as a second param and not only the eqFunction. This will make it possible to add other options without breaking the api.

The reason I raise this now is that I will quite likely open a new issue in the coming days and pitch allowing passing i custom areStatesEqual function to createUseSelector.

[timdorr]

@antonobergklarna No need. That's exactly what this issue is discussing.

[antonobergklarna]

@timdorr - My interpretation of this discussion is that we are talking about the equalityFn that is used to compare the result returned by the selector (i guess analog to areStatePropsEqual in connect). I want an areStatesEqual that will replace storeState !== latestStoreState.current and default to refEquality.

The second argument to createUseSelector could be an optional object where you could provide both
{ areStatesEqual, equalityFn }.

If an object notation feels like a good idea I think that it will also make sense to challenge the name equalityFn and use something like areSelectedPropsEqual or areDerivedDataEqual

[williamisnotdefined]

Sorry for my ignorance but..

const MySelector = (selector) => { return useSelector(selector, yourOwnEqualityFn) }

That hook doesnt solve the problem?

[timdorr]

Actually, yeah, that would be much easier than changing our API. You need to create a hook anyways, and it doesn't have to come from the factory function.