Arguments to callback prop of generic React component are not inferred

[Mesoptier]

Bug Report

🔎 Search Terms

react, polymorphic components, generic components, type inference on function arguments

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about type inference on function arguments

⏯ Playground Link

Playground link with relevant code

💻 Code

import React from 'react';

type Props<T extends React.ElementType> =
  { as: T } & Omit<React.ComponentPropsWithoutRef<T>, 'as'>;

declare function Button<T extends React.ElementType>(props: Props<T>): JSX.Element;

// Using Button as React component (intended use case):

// OK: The type of `Button` is `function Button<"button">(props: Props<"button">): JSX.Element` in this instance.
<Button
  as="button"
  // OK: The type of `onClick` is `(JSX attribute) onClick?: React.MouseEventHandler<HTMLButtonElement> | undefined`.
  // NOT OK: The type of `e` is `any` (implicitly).
  onClick={(e) => { console.log(e); }}
/>;

// Using Button as regular function (same issue):

// OK: The type of `Button` is `function Button<"button">(props: Props<"button">): JSX.Element` in this instance.
Button({
  as: 'button',
  // OK: The type of `onClick` is `(property) onClick?: React.MouseEventHandler<HTMLButtonElement> | undefined`.
  // NOT OK: The type of `e` is `any` (implicitly).
  onClick: (e) => { console.log(e); },
});

🙁 Actual behavior

The argument e to the callback function provided to onClick implicitly has any type.

🙂 Expected behavior

I would expect the checker to know that the type of e can only be React.MouseEvent<HTMLButtonElement, MouseEvent>.

The checker seems to know that the type of the onClick callback is React.MouseEventHandler<HTMLButtonElement>, which in turn resolves to (event: React.MouseEvent<HTMLButtonElement, MouseEvent>) => void. So I would expect the checker to be able to use that information to determine the type of e / event.

[Mesoptier]

I've looked into this some more. If I make the onClick prop required (i.e. remove the | undefined), the inference starts working correctly. However, this is obviously not desirable, since the onClick prop is optional for a reason.

Playground link with relevant code

import React from 'react';

type MakeRequired<T, K> = K extends keyof T ? Omit<T, K> & Required<Pick<T, K>> : T;

type Props<T extends React.ElementType> =
  { as: T } & MakeRequired<Omit<React.ComponentPropsWithoutRef<T>, 'as'>, 'onClick'>;

declare function Button<T extends React.ElementType>(props: Props<T>): JSX.Element;

// Using Button as React component (intended use case):

// OK: The type of `Button` is `function Button<"button">(props: Props<"button">): JSX.Element` in this instance.
<Button
  as="button"
  // OK: The type of `onClick` is `(JSX attribute) onClick: React.MouseEventHandler<HTMLButtonElement>`.
  // OK: The type of `e` is `(parameter) e: React.MouseEvent<HTMLButtonElement, MouseEvent>`.
  onClick={(e) => { console.log(e); }}
/>;

// Using Button as regular function (same issue):

// OK: The type of `Button` is `function Button<"button">(props: Props<"button">): JSX.Element` in this instance.
Button({
  as: 'button',
  // OK: The type of `onClick` is `(property) onClick: React.MouseEventHandler<HTMLButtonElement>`.
  // OK: The type of `e` is `(parameter) e: React.MouseEvent<HTMLButtonElement, MouseEvent>`
  onClick: (e) => { console.log(e); },
});

[RyanCavanaugh]

We can take a look earlier if someone can remove the react dependency from the repro, since it's entirely possible there's something in the definition that causes this per expected behavior.

[Mesoptier]

After reading your comment I also searched through the issue tracker on DefinitelyTyped. There I found this issue for @types/react which looks similar to what I'm describing: DefinitelyTyped/DefinitelyTyped#50459. According to that, this might an issue with the React typings. However, I'll continue trying to reproduce the issue without the react dependency.

[Mesoptier]

I've altered my original code sample to no longer include the react dependency. Instead it now includes a few minimal types based on those found in @types/react, which is still enough to demonstrate the issue somewhat succinctly. Hopefully this will help in narrowing down on the issue.

Playground link

Interestingly, if I comment line 19 (| ElementConstructor<P>), the issue disappears.

Playground link with relevant line commented

I can see how this might suggest that the issue lies within @types/react. However, the fact remains that TypeScript seems to be able to correctly resolve the type of the onClick callback (including its event argument), but not propagate that information to the type of the actual argument e in the provided callback.

---

Edit: I see now that the JSX namespace is no longer included, leading to some squiggly red error lines. Adding import React from 'react'; should fix those. Then the dependency is only used for TypeScript to understand the JSX part and does not impact the issue described in any way.

[Mesoptier]

Looking at this comment from earlier, I realised that it probably wasn't the "making the prop required" part of it all that made it work. I removed the Required<> utility type, and kept only the Pick<> and it still seems to work.

- type MakeRequired<T, K> = K extends keyof T ? Omit<T, K> & Required<Pick<T, K>> : T;
+ type FixCallback<T, K> = K extends keyof T ? Omit<T, K> & Pick<T, K> : T;

More interestingly, applying this fix to the onClick handler only will also make the onBlur event handler work in the function case, but NOT in the JSX case!

Playground link

import React from 'react';

type FixCallback<T, K> = K extends keyof T ? Omit<T, K> & Pick<T, K> : T;

type Props<T extends React.ElementType> =
  { as: T } & FixCallback<Omit<React.ComponentPropsWithoutRef<T>, 'as'>, 'onClick'>;

declare function Button<T extends React.ElementType>(props: Props<T>): JSX.Element;

// Using Button as React component (intended use case):

// OK: The type of `Button` is `function Button<"button">(props: Props<"button">): JSX.Element` in this instance.
<Button
  as="button"
  // OK: The type of `onClick` is `(JSX attribute) onClick: React.MouseEventHandler<HTMLButtonElement>`.
  // OK: The type of `e` is `(parameter) e: React.MouseEvent<HTMLButtonElement, MouseEvent>`.
  onClick={(e) => { console.log(e); }}
  // NOT OK: The type of `e` is `any`.
  onBlur={(e) => { console.log(e); }}
/>;

// Using Button as regular function (same issue):

// OK: The type of `Button` is `function Button<"button">(props: Props<"button">): JSX.Element` in this instance.
Button({
  as: 'button',
  // OK: The type of `onClick` is `(property) onClick: React.MouseEventHandler<HTMLButtonElement>`.
  // OK: The type of `e` is `(parameter) e: React.MouseEvent<HTMLButtonElement, MouseEvent>`.
  onClick: (e) => { console.log(e); },
  // OK (Somehow?!): The type of `e` is `(parameter) e: React.FocusEvent<HTMLButtonElement>`.
  onBlur: (e) => { console.log(e); },
});

[quantizor]

@RyanCavanaugh I see that this is marked as backlog. A lot of people in the FE world use this prop inference pattern... would be good to at least target a milestone for fixing it.

[devanshj]

We can take a look earlier if someone can remove the react dependency from the repro, since it's entirely possible there's something in the definition that causes this per expected behavior.

Here's the react free version @RyanCavanaugh asked for. Playground. (Uses react import just for the JSX.IntrinsicElements definition).

import React from "react";

declare const Identity:
  <C extends keyof JSX.IntrinsicElements>
    (props: { as?: C } & JSX.IntrinsicElements[C]) => 
      JSX.Element

<Identity
  as="input"
  onChange={value => {
    // value is any, expected string
  }}
  value="foo" />

Identity({
  as: "input",
  onChange: value => {
    // value is string, expected string
  },
  value: "foo"
})

[Mesoptier]

We can take a look earlier if someone can remove the react dependency from the repro, since it's entirely possible there's something in the definition that causes this per expected behavior.

@RyanCavanaugh OK, I now have an actual react-free reproduction case for this issue. One thing to note is that I've set TypeScript's JSX option to 'Preserve', to avoid errors from using JSX syntax without a React import.

Playground link

interface Elements {
  foo: { callback?: (value: number) => void };
  bar: { callback?: (value: string) => void };
}

type Props<C extends keyof Elements> = { as?: C } & Elements[C];
declare function Test<C extends keyof Elements>(props: Props<C>): null;

<Test
  as="bar"
  callback={(value) => {
    // expected: typeof value = string
    // actual: typeof value = any (implicitly)
    // NOT OK
  }}
/>;

Test({
  as: "bar",
  callback: (value) => {
    // expected: typeof value = string
    // actual: typeof value = string
    // OK
  },
});

<Test<'bar'>
  as="bar"
  callback={(value) => {
    // expected: typeof value = string
    // actual: typeof value = string
    // OK
  }}
/>;

---

It still seems so weird to me that the type of the callback is correct, but the type of the callback parameter is not: