Repository navigation
Inconsistent behavior with Generic ElementTypeย #61995
Description
Activity
MartinJohns commented
on Jul 4, 2025 ContributorMore actionsDuplicate of #54851.
This is slightly different to that old case, because that was simply a case where the resulting element was incorrectly typed. Here is something that clearly should compile, but doesn't, and with an error message that gives very little help in determining the reason. (and super-frustratingly, implies that the complier has, in fact, correctly inferred the type...)
<pause to reflect briefly on the disappointment of discovering a 6-year old PR (#29818) that would fix the underlying issue>.
I get the problem, but it seems like just making JSX a forever-only-partially-typed subset of the language due to performance issues and one particular dominant use case (react) is a poor decision. JSX could be a very useful idiom for constructing DSLs outside of React - my own use case is for composing workflows. When constructing such DSLs performance may be less of an issue because nesting is less deep or the number of components much smaller.
My expectation was that type checking would work much as it does in the rest of the language, which clearly is not the case. It would be useful to see the documentation improve. Here: https://www.typescriptlang.org/docs/handbook/jsx.html it does say 'You can customize the type by specifying the JSX.Element interface. However, it is not possible to retrieve type information about the element, attributes or children of the JSX from this interface. It is a black box'. I think the latter part alludes to this issue, but I think something along the lines of 'type parameters of JSX.Element will never be inferred' would be clearer.
So I can only add to the chorus of people suggesting under cover of that old PR that this is something that could be legitimately conditioned under a feature flag.
Reacted by Jonathan Hefner- addedHelp WantedYou can do thisYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some casesThe current behavior isn't wrong, but it's possible to see that it might be better in some cases
on Jul 7, 2025 - addedDomain: JSX/TSXRelates to the JSX parser and emitterRelates to the JSX parser and emitter
on Oct 15, 2025
๐ Search Terms
JSX, Generic ElementType, TS2786
๐ Version & Regression Information
โฏ Playground Link
No response
๐ป Code
๐ Actual behavior
Compile error:
sui.tsx:31:6 - error TS2786: 'Form' cannot be used as a JSX component.
Its type '(props: { name: U; }, ...children: Element[]) => { type: string; children: Element[]; name: U; }' is not a valid JSX element type.
Types of parameters 'props' and 'props' are incompatible.
Type '{ name: unknown; }' is not assignable to type '{ name: string; }'.
Types of property 'name' are incompatible.
Type 'unknown' is not assignable to type 'string'.
31
๐ Expected behavior
Changing props: { name: U } in the definition of ElementType to props: { name: string } causes the code to compile [loosing the wanted typing of the resulting Element
Since the desugared version of the code compiles and infers types correctly, I'd expect the JSX code to compile, or at least produce a less deeply mysterious error - the type of the 'name' property plainly isn't unknown.
Additional information about the issue
No response