Definitelytyped: [@types/react] Prameter type definition between useMemo and useCallback is different, but the origin is same

[khg0712]

Is something wrong with CI or publishing infrastructure?

• Check the Infrastructure status updates thread for known issues.
• Leave a message on the DefinitelyTyped Gitter.

If you know how to fix the issue, make a pull request instead.

• [x] I tried using the @types/react package and had problems.
• [ ] I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• [ ] I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• [x] [Mention](https://github.com/blog/821-mention-somebody-they-re-notified) the authors (see Definitions by: in index.d.ts) so they can respond.
  
  
  
  • Authors: @johnnyreilly @bbenezech @pzavolinsky @digiguru @ericanderson @DovydasNavickas @theruther4d @guilhermehubner @ferdaber @jrakotoharisoa @pascaloliv @hotell @franklixuefei @Jessidhia @saranshkataria @lukyth @eps1lon @zieka @dancerphil
  
  

---

updated issue

I recognized why it should have different type each @types/react and react. (It means not difference of flow and typescript but difference of type definition between @types/react and react.)

My issue is that param type of useCallback and useMemo is same in react. but, it is different in @types/react.
I think it is inconsistent. because the reason of difference between @types/react and react only applies to useCallback. I think param type of useMemo should be changed.

---

origin issue

I have watched origin code of react hooks (specipically useCallback) here.
But the type of useCallback was different from useCallback of @types/react

type DependencyList = ReadonlyArray<any>;
function useCallback<T extends (...args: any[]) => any>(
  callback: T,
  deps: DependencyList
): T;

type definition of @types/react

function useCallback<T>(
  callback: T,
  deps: Array<mixed> | void | null, //void is undefined in flow
): T

type definition of react(origin)

Why useCallback has different type definition from origin? and other hooks are different too.

ps. If it should be fixed, I want to fix it. thx

[eps1lon]

Why useCallback has different type definition from origin?

The React repo is typed in flow. flow has slightly different syntax which explains the literal difference in code.

Is there a specific type problem you're facing?

[khg0712]

@eps1lon
In @types/react, type of parameter deps is DependencyList. DependencyList type includes only array type.
On the other hand, in react, type of parameter deps is Array<mixed> | void | null.

I don't know flow in detail. but It seems strangely. DependencyList must include not only ReadonlyArray<any> but also undefined and null

[ferdaber]

Sure in real life you could call useCallback or useMemo without a dependency array, but in practice you would never want to do that, since at that point those are just IIFEs.

Having the second parameter be mandatory non-nullable allows better static analysis of the 99.99% use case which is someone forgetting to put in the second parameter.

[khg0712]

@ferdaber
I thought that type definition of @types/react should implement origin react's.
But now I got understanding difference of type definition is for following intention of react hooks. 👍

[khg0712]

@ferdaber
Then both useCallback and useMemo should have notnull deps param.
But, deps param of useMemo is DependencyList | undefined (see here)
I think it is very contradictory.

ps. Actually, there is a comment deps param of useMemo allows undefined, but it is mostly a mistake.

[eps1lon]

ps. Actually, there is a comment deps param of useMemo allows undefined, but it is mostly a mistake.

Yeah, I'm not happy with that comment either. It doesn't explain what the actual use case would be. Just that there is one without considering it might not actually be one.

Maybe @Jessidhia can shed some light?

[ferdaber]

IIRC someone reported a 0.01% use case where they wanted to explicitly pass in undefined, and they wanted to be able to do it without using the non null assertion parameter, so this was the compromise that we had: forcing the second parameter, but allowing undefined.

[khg0712]

so this was the compromise that we had: forcing the second parameter, but allowing undefined.

@ferdaber

Such rules must be consistent. useCallback isn't allowed undefined but useMemo allowed undefined. Same rules must be applied to not only useMemo, but also useCallback.

[eps1lon]

Such rules must be consistent.

There's no "must" here. React core members even approved the original change so I don't think we need to change something because you're of the opinion that we "must" do something.

[khg0712]

There's no "must" here. React core members even approved the original change so I don't think we need to change something because you're of the opinion that we "must" do something.

@eps1lon I'm sorry if you felt forced.It wasn't intended. I thought it was weird that different rules are applied to same condition.

But if you recognized it and it is no matter to you. It is ok. It would be ok to close this issue.🙂