[react-redux] useSelector can infer its return type with shallowEqual

[kazuma1989]

Hi. I have an issue with a combination of useSelector and shallowEqual (described below). I'd like to fix the issue!

The return type of useSelector is perfectly inferred:

type State = { foo: string; };
const foo = useSelector((state: State) => state.foo);
// foo is string

But with shallowEqual, the return type is not inferred so it gets to be any:

const foo = useSelector((state: State) => state.foo, shallowEqual);
// foo is any

A minimal repro is here: https://github.com/kazuma1989/repro-shallowEqual-missing-types

@dt-bot

---

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/kazuma1989/repro-shallowEqual-missing-types
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

[typescript-bot]

@kazuma1989 Thank you for submitting this PR!

🔔 @tkqubo @kenzierocks @clayne11 @tansongyang @NicholasBoll @mDibyo @Kallikrein @val1984 @jrakotoharisoa @apapirovski @surgeboris @soerenbf @MrWolfZ @DylanVann @Lazyuki - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#41540	diff
Batch compilation
Memory usage (MiB)	132.4	123.1	-7.0%
Type count	34748	34755	0%
Assignability cache size	61426	61432	0%
Language service
Samples taken	1842	1846	0%
Identifiers in tests	1842	1846	0%
getCompletionsAtPosition
Mean duration (ms)	549.4	543.2	-1.1%
Mean CV	7.7%	7.6%
Worst duration (ms)	760.8	777.4	+2.2%
Worst identifier	Test	Test
getQuickInfoAtPosition
Mean duration (ms)	544.5	539.6	-0.9%
Mean CV	8.2%	8.5%	+3.9%
Worst duration (ms)	750.7	697.7	-7.0%
Worst identifier	createElement	own

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[typescript-bot]

@kazuma1989 One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits or comments. Thank you!

[typescript-bot]

A definition owner has approved this PR ⭐️. A maintainer will merge this PR shortly. If it shouldn't be merged yet, please leave a comment saying so and we'll wait. Thank you for your contribution to DefinitelyTyped!

[Lazyuki]

Can you add another test with a correctly inferred type just to be sure?

[typescript-bot]

🔔 @Lazyuki - Thanks for your review of this PR! Can you please look at the new code and update your review status if appropriate?

[uniqueiniquity]

Congratulations on your first DefinitelyTyped contribution!
Thank you for being a part of the community!

[typescript-bot]

I just published @types/react-redux@7.1.7 to npm.