TypeScript: Bug: Valid programs with JSX fail to typecheck when JSX is de-sugared

πŸ”Ž Search Terms

jsx children

πŸ•— Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about jsx

⏯ Playground Link

Playground link with relevant code

πŸ’» Code

import React from 'react'

// This example comes from https://github.com/vercel/next.js/blob/5544adc481f8821567e947a6e6d51d9d68ebd367/packages/next/shared/lib/head.tsx#L172
declare function Head({ children }: {
    children: React.ReactNode;
}): JSX.Element;

// This typechecks
const PageWithJSX = () => (
    <Head>
        <title>Hello</title>
    </Head>
)

// This does not typecheck
const PageWithoutJSX = () => React.createElement(Head, {},
    React.createElement('title', {}, 'Hello'),
)

πŸ™ Actual behavior

The non-JSX code gives the type error:

No overload matches this call.
  The last overload gave the following error.
    Argument of type '{}' is not assignable to parameter of type 'Attributes & { children: ReactNode; }'.
      Property 'children' is missing in type '{}' but required in type '{ children: ReactNode; }'.(2769)
input.tsx(5, 5): 'children' is declared here.

πŸ™‚ Expected behavior

No type error should be given, because it’s just the same as the code that does type-check, only without JSX.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 16 (5 by maintainers)

Most upvoted comments

We can currently write a DOM tree using hyperscript-style code with nested function calls and get types. I don’t see why not simply extend this to JSX syntax.

@RyanCavanaugh interesting. I’m biased since I don’t use JSX, but I would almost always take a slower compiler over an inaccurate one.

Why the confused face @RyanCavanaugh ? The performance of nested function calls is that bad?

JSX is syntax for something we can otherwise already do with nested function calls, and therefore I believe JSX should benefit from the same sort of typing.