Issue with importing components with render props

[lalnuo]

If component takes React.FunctionComponent as a prop it can not be typed:

https://gist.github.com/lalnuo/f8f3728476e9535115815dae97657eab

[cristianoc]

While (_1: renderMeProps) => JSX.Element is converted automatically to React.FC<renderMeProps>, this does not work inside a React.FC<....>: inside that, conversion does not work in either direction.

This means that to support your example, renderMe should be checked against React.FC<renderMeProps>. But, to support the other example where an explicit function type is used in Foo.tsx, renderMe should be checked against (_1: renderMeProps) => JSX.Element.

This is a super-verbose way to support both forms:

export const makeTypeChecked:
  | React.FC<{
      readonly renderMe: (_1: renderMeProps) => JSX.Element;
    }>
  | React.FC<{
      readonly renderMe: React.FC<renderMeProps>;
    }> = makeNotChecked;

Not sure at this point what a decent solution would look like.

[Coobaha]

slightly more compact will be to use union type for renderMe?

export const makeTypeChecked: React.FC<{
      readonly renderMe:  React.FC<renderMeProps> | (_1: renderMeProps) => JSX.Element;
    }> = makeNotChecked;

[cristianoc]

@Coobaha that compact representation would not work.

Turns out, these 3 types are just incompatible:

export type tnum = React.FC<{ x: number }>;
export type tstr = React.FC<{ x: string }>;
export type teither = React.FC<{ x: string | number }>;

Any conversion between them gives a type error.

While for the corresponding function types, contravariance applies to the function arguments.

So it looks like as soon as one moves to the React.FC<...> types, typing becomes more rigid.

[cristianoc]

One conversion that does work is from

React.FC<{ x: number }>

to

React.FC<{ x: number, y: number }>

But if those are render props inside React.FC<...>, then conversion in neither direction is supported.

[cristianoc]

Il looks like there are a number of gotchas when working with React.FC independent from interop with Reason. Also, not sure how changeable these details are in future.

One possibility would be to just use React.FC for all types in a component import, so just inheriting the existing gothas that people would have to face anyway. This assumes that React.FC is widely used -- would be good to confirm that.

[cristianoc]

Here's an attempt :#211.

It relies on inlining the type of the render prop as it would come out of the PPX:

external make:
  (
    ~person: person,
    ~children: React.element,
    ~renderMe: {. "randomString": string} => React.element
  ) =>
  React.element

[cristianoc]

Here's a more aggressive version: #212.
In the more aggressive version, all the values of type function component are represented as React.FC<...>.
It's more aggressive in that it applies to exported values as well. So the TS consumer of an exported function would not be able to type it as a function, but would need to go with React.FC<...>.

On the other side it's more regular, in that there are fewer corner cases. (E.g. if the renderMe type is defined separately, then it can be used both for import and export, so having it all treated in the same way reduces surprises).

Tradeoffs...

[cristianoc]

Handled in release https://github.com/cristianoc/genType/releases/tag/v2.30.0.