react-redux/useSelector-prefer-selectors returns false positive/negative when passing additional params

[mladenoff]

If we have a selector like export const selectUser = (state, id) => state.users[id] that requires additional parameters passed to it from the component (in this case, id), this rule gives us useSelector should use a named selector function.eslint(react-redux/useSelector-prefer-selectors) when used in the component like const user = useSelector((state) => selectLead(state, id)).

It is worth noting that this is the syntax recommended by the Redux docs (when a memoized selector is not needed).
If we write a currying selector like export const selectUser = (id) => (state) => state.users[id] and use it in the component like const user = useSelector(selectUser(id)) the rule passes.

I don't think this current behavior follows the letter or the spirit of the rule as written. The return value of selectUser(id) is very much not a named function and we are creating a new function just as much as we are with the non-curried selector wrapped in the arrow function. I think the false positive here is because of

      if (selector && (
        selector.type === 'ArrowFunctionExpression' ||
        selector.type === 'FunctionExpression')
      ) {
        reportNoSelector(context, node);

in lib/rules/useSelector-prefer-selectors.js

Given all this it seems like the current rule is more accurately named react-redux/useSelector-prefer-named-selectors as alluded to by @DianaSuvorova in #54 (comment) on #54. It looks like the description was changed but the rule name was not changed, I guess to follow the pattern from react-redux/mapStateToProps-prefer-selectors?

With the current name it seems like the rules wants some additional options, but I am not entirely sure on how to implement them. I guess one to permit an anonymous function passed to useSelector when it contains a named function (can we even check for this? And maybe another to forbid/allow the curried named function as "selector creator"?

[DianaSuvorova]

@mladenoff thanks for the detailed explanation of the issue. Sounds like the name of the rule is miss-leading, if you can create a PR to change the name, I would be happy to review/approve it 😊
Sounds like renaming the rule should be the most straightforward way to avoid the confusion, let me know if you have other recommendations instead.