react-redux: add types for hooks which will be added in version 7.1

[MrWolfZ]

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

Select one of these and delete the others:

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/reduxjs/react-redux/tree/v7-hooks-alpha/src/hooks
• Increase the version number in the header if appropriate.
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }.

I am the author of the react-redux alpha hooks implementation (which I prototyped in TypeScript). These type definitions are mostly taken from my own source code.

[typescript-bot]

@MrWolfZ Thank you for submitting this PR!

🔔 @tkqubo @kenzierocks @clayne11 @tansongyang @NicholasBoll @mDibyo @Kallikrein @val1984 @jrakotoharisoa @apapirovski @surgeboris @soerenbf - 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.

[threehams]

I'm still running tests locally, but we can likely replace all these overloads with a single T extends ReadonlyArray<readonly ActionCreator<A>>. That prevents the action creator tuple from getting widened to an array.

[the-dr-lazy]

Typescript couldn't infer the type of data in every index without tuples for now.

// With action creator tuples
useAction([a, b]) //=> [A, B]

// Without action creator tuples
useAction([a, b]) //=> (A | B)[]

[threehams]

Looks like it only works properly on TypeScript 3.4 and above. Too bad, but it's a good option for a couple months from now...

[the-dr-lazy]

Is it possible to release a major version that has a peer dependency on typescript@^3.4 now?

[MrWolfZ]

The compatibility with TypeScript 3.0 is exactly the reason why I typed it this way. I think these typings are just bearable enough that I wouldn't want to bump the peer dependency just for this. In a couple of months it's an easy fix.

[typescript-bot]

@MrWolfZ The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[the-dr-lazy]

I think there is no need for the A = AnyAction. Actually, this generic type looks useless. Also, it causes problems with some Redux middlewares like redux-thunk. Maybe it is better to replace it with any.

[MrWolfZ]

The reason I did it this way is to be similar to how bindActionCreators from redux is typed. I don't think it hurts to have that extra generic parameter since in pretty much all cases you are not going to specify any of the parameters anyways. However, as you say, it can easily be replaced with any or AnyAction, so if you still think I should remove it, I will do so.

[the-dr-lazy]

Let's have a minimal implementation for it without extra generics. Also, it is important to don't restrict action creator return type to AnyAction for compatibility with thunks or other similar middlewares.

[the-dr-lazy]

Please see MrWolfZ/DefinitelyTyped#1.

[MrWolfZ]

I have merged the PR.

[threehams]

I think we need feedback from more people on this. Redux bound actions are obnoxiously difficult to type since the return value is determined by the middleware you're running. We can't solve every case of this, but in the most basic case of this, setting this to any will cause a lot of errors since we can't do conditional checking between action creators (which return an object) and thunks (which return whatever the thunk returns).

The existing typings have built-in support for redux-thunk, for instance, which is missing from these types:

TActionCreator extends (
    ...args: infer TParams
  ) => (...args: any[]) => infer TReturn
    ? (...args: TParams) => TReturn
    : TActionCreator

Minimal example:

const thunkAction = () => () => {
  return { success: true };
}

const result = useActions(thunkAction);
  if (result.success) { // Property 'success' does not exist on type '() => () => { success: boolean; }'.
  }
}

@surgeboris and @rhys-vdw had to resolve a middleware-related bug/conflict in #30740, so they may have a specific interest here.

[threehams]

I'll work on a PR tonight to allow any function as an action, but still support thunk return values. That should cover the simplest cases. It shouldn't be anywhere near as difficult as connect() has been.

I'll also add some tests so we're not guessing anymore.

[rhys-vdw]

Hey @threehams, just responding to the mention. Don't think I've got anything of value to add here as I haven't really dug into hooks yet, but thanks for the heads up. I'll keep an eye on the issue nonetheless.

[typescript-bot]

@MrWolfZ 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]

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

[typescript-bot]

@MrWolfZ The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[threehams]

The object form has the same issue of not supporting thunks (or any random middleware-allowed action creator) as the other forms. I can take care of that tonight along with the other thunk changes.

[threehams]

Sorry, I have no idea how to do a pull request into your fork (doesn't seem to let me compare?)

This commit supports thunk return values, and adds test coverage for all hooks:
threehams@6459ed2

[MrWolfZ]

@threehams thanks, I have tried manually merging your changes into my fork. However, I get errors during linting:

ERROR: 1338:15  expect                   Compile error in typescript@3.0 but not in typescript@3.1.
Fix with a comment '// TypeScript Version: 3.1' just under the header.
Type 'ResolveArrayThunks<[(selected: boolean) => { type: string; payload: boolean; }, ({ items }: { items: string[]; }) => { type: string; payload: { items: string[]; }; }, () => (dispatch: Dispatch<AnyAction>) => { type: string; payload: never[]; }]>' is not an array type.
ERROR: 1354:15  expect                   Compile error in typescript@3.0 but not in typescript@3.1.
Fix with a comment '// TypeScript Version: 3.1' just under the header.
Type 'ResolveArrayThunks<[(selected: boolean) => { type: string; payload: boolean; }]>' is not an array type.
ERROR: 1462:13  expect                   Compile error in typescript@3.0 but not in typescript@3.1.
Fix with a comment '// TypeScript Version: 3.1' just under the header.
Type 'ResolveArrayThunks<[(selected: boolean) => { type: string; payload: boolean; }, ({ items }: { items: string[]; }) => { type: string; payload: { items: string[]; }; }, () => (dispatch: Dispatch<AnyAction>) => { type: string; payload: never[]; }]>' is not an array type.

I think the issue is with mapped types and tuples in 3.0. Therefore, we can either bump the TS version to 3.1, or we need to create a version of ResolveTupleThunks for each overload.

[MrWolfZ]

Oh, and another thing I noticed is that useDispatch doesn't allow dispatching thunks, but that is because the typing of Dispatch itself only allows actions to be dispatched. Any idea of how to work around this?

[markerikson]

We're not actually using Object.is() or its equivalent right now - it's just a straight-up reference ===.

[MrWolfZ]

@markerikson Are you maybe confusing this with something else? The shallowEqual function is using Object.is() as you can see here.

[markerikson]

Whoops, yeah :)

[renchap]

Similar to how you can define you own useDispatch hook when you use redux-thunk to have proper typing, I think it would be useful to have an easy and documented way to have your own useSelector that you can export along your store and custom useDispatch, so you do not need to retype the state arg each time you use useSelector.

For example:

// Current version
import { useSelector } from "react-redux"
import { RootState } from "store"

const currentUser = useSelector((state: RootState) => state.currentUser)

// With proposal
import { useSelector } from "store"

const currentUser = useSelector(state => state.currentUser)

You can currently achieve this with something like:

import { useSelector as useSelectorBase } from "react-redux"

export const useSelector = <TSelected>(
  selector: (state: RootState) => TSelected,
  equalityFn?: (left: TSelected, right: TSelected) => boolean,
): TSelected => useSelectorOrig(selector, equalityFn)

which is a bit verbose because you need to repeat the TSelected template parameter. Would it be possible to have a more concise (and update-proof) way of typing your own useSelector?

[MrWolfZ]

@renchap I actually think that your example code isn't too bad, especially since you only need one of those in your app. However, what we could add something like this:

export interface TypedUseSelectorHook<TState> {
    <TSelected>(
        selector: (state: TState) => TSelected,
        equalityFn?: (left: TSelected, right: TSelected) => boolean
    ): TSelected
}

// use it like this
interface RootState {
  currentUser: CurrentUser;
}

const useTypedSelector: TypedUseSelectorHook<RootState> = useSelector;

What do you think?

[renchap]

@MrWolfZ Yes I has something like this in mind. For me there are 2 goals:

• Have this documented somewhere, so people know they can use this pattern of custom hooks with pre-typed state (similar to useDispatch)
• Be less dependent of the types implementation, so if the typings change you dont need to update your custom hook definition

Your proposal seems to solve both items :)

[MrWolfZ]

I've added the TypedUseSelectorHook interface to the type definitions. I've also added a paragraph to the useSelector comment that mentions this new interface. I am not sure if there is a better way of making people aware of its existence.

[typescript-bot]

👋 Hi there! I’ve run some quick performance metrics against master and your PR. This is still an experiment, so don’t panic if I say something crazy! I’m still learning how to interpret these metrics.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#34913	diff
Batch compilation
Memory usage	145944760.0	152659792.0	+4.6%
Type count	66229	66441	+0.3%
Assignability cache size	60423	60467	+0.1%
Subtype cache size	2523	2523	0.0%
Identity cache size	1152	1153	+0.1%
Language service
Samples taken	1583	1733	+9.5%
Identifiers in tests	1583	1733	+9.5%
getCompletionsAtPosition
Mean duration (ms)	692.1	703.3	+1.6%
Median duration (ms)	683.9	697.5	+2.0%
Mean CV	5.7%	5.3%	-6.2%
Worst duration (ms)	919.3	951.6	+3.5%
Worst identifier	ConnectedWithOwnPropsStateless	ConnectedWithOwnPropsClass
getQuickInfoAtPosition
Mean duration (ms)	592.6	602.3	+1.6%
Median duration (ms)	579.3	590.1	+1.9%
Mean CV	6.4%	6.0%	-6.1%
Worst duration (ms)	870.0	900.1	+3.5%
Worst identifier	own	TestUndefined

It looks like nothing changed too much. I’m pretty lenient since I’m still an experiment, so take a look anyways and make sure nothing looks out of place.

---

If you have any questions or comments about me, you can ping @andrewbranch. Have a nice day!

[RIP21]

@markerikson hey :) 7.1 got released, having this merged and published would be awesome :P

[markerikson]

@RIP21 : we don't control the typings at all :) that's up to the community.

[RIP21]

@markerikson Aha :P Gotcha. Saw you on reviewers list, thought that you are related to release somehow :)

Reviewers pleeeeease, make this one happen :)

[typescript-bot]

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