Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
gkemp94 opened this issue Aug 24, 2022 · 4 comments Β· Fixed by #59933
Closed

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

gkemp94 opened this issue Aug 24, 2022 · 4 comments Β· Fixed by #59933
Assignees
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue Rescheduled This issue was previously scheduled to an earlier milestone

Comments

@gkemp94
Copy link

gkemp94 commented Aug 24, 2022

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
Copy link
Contributor

Playground link

@RyanCavanaugh RyanCavanaugh added the Bug A bug in TypeScript label Aug 26, 2022
@RyanCavanaugh RyanCavanaugh added this to the TypeScript 4.9.0 milestone Aug 26, 2022
@a-tarasyuk
Copy link
Contributor

@RyanCavanaugh Should JsxOpeningFragment be part of CallLikeExpression?

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
Copy link
Member

DanielRosenwasser commented Nov 2, 2022

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.

@RyanCavanaugh RyanCavanaugh added the Rescheduled This issue was previously scheduled to an earlier milestone label Feb 1, 2023
kdy1 added a commit to dudykr/stc that referenced this issue Apr 8, 2023
**Description:**

TypeScript does not validate JSX Fragments properly.

**Related issue:**

 - microsoft/TypeScript#50429
@merrywhether
Copy link

merrywhether commented Sep 12, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue Rescheduled This issue was previously scheduled to an earlier milestone
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants