JSX Fragments are in-properly typed when not using React.Fragment

[gkemp94]

Bug Report

🔎 Search Terms

React Fragment

🕗 Version & Regression Information

I believe this is a new inconsistency due to changes in React.

⏯ Playground Link

https://github.com/gkemp94/test-typescript-fragment

Code

import React from "react";

const test = () => "asd";

// No Errors
const jsxWithJsxFragment = <>{test}</>;

// Type '() => string' is not assignable to type 'ReactNode'.
const jsxWithReactFragment = <React.Fragment>{test}</React.Fragment>;

🙁 Actual behavior

When using <> vs <React.Fragment> the children are not properly type checked

🙂 Expected behavior

When jsx: react is specified, to type check <> the same as React.Fragment

[MartinJohns]

Playground link

[a-tarasyuk]

@RyanCavanaugh Should JsxOpeningFragment be part of CallLikeExpression?

TypeScript/src/compiler/types.ts

Lines 2802 to 2808 in ed6889c

	export type CallLikeExpression =
	| CallExpression
	| NewExpression
	| TaggedTemplateExpression
	| Decorator
	| JsxOpeningLikeElement
	;

It does not have tagName (which we use in JsxOpeningLikeElement to resolve call) and other common CallLikeExpression properties - attributes, typeArguments, etc.

Or do we need to make a special kind of fragment factory (with a synthetic name) call resolving?

[DanielRosenwasser]

It sounds like the answer is "yes it should be a call-like expression", but also you will need to virtualize a target. I don't know if we still do that, but we have helpers like getEffective____ for getting the arguments we should check against.

[merrywhether]

Could this be solved in a similar manner to #51328? Libraries/types could define something like JSX.FragmentType in addition to JSX.ElementType and have full control over their JSX.