Allow JSX.Element to take a generic parameter for more control over the return type.

[SCLeoX]

Suggestion

🔍 Search Terms

JSX, JSX.Element, TSX, React

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

JSX.Element is used to determine the return type of a jsx tag. For example, if I have:

declare namespace JSX {
  type Element = string;
  type IntrinsicElements = { test: {} }
}

When I write

const a = <test/>;

The type of a is string.

I hope instead of always returning JSX.Element, it can return something like JSX.Element<"test">. (i.e. type of the tag name is passed in as a generic parameter.)

📃 Motivating Example

I am trying to use tsx without React. I get everything else working, except I have to define JSX.Element as HTMLElement. Which means, when I write

const myElement = <a href="#">Hello</a>;

The type of myElement is HTMLElement, instead of (ideally) HTMLAnchorElement.

If this feature is implemented, I can then write:

declare namespace JSX {
  type Element<T extends string> = T extends keyof HTMLElementTagNameMap
    ? HTMLElementTagNameMap[T]
    : HTMLElement;
}

As a result, myElement in the above example should have type HTMLAnchorElement instead of a boring HTMLElement.

💻 Use Cases

The current workaround I am using is do a type cast after every JSX tag, which is not that ideal.

[MartinJohns]

I think you want: #21699

[RyanCavanaugh]

Yeah, #21699 is the only plausible way we could do this

[SCLeoX]

Thanks for linking that issue. I don't mind this is marked as a duplicate and #21699 will indeed solve my specific use case. However, I don't think that issue you link is going anywhere, because although that solution is correct and objectively superior, the fact that it hasn't been solved is probably because there are some technical limitations and not enough interests. Maybe the solution I proposed here can still be considered as one potential (though probably worse) way to this issue.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

I'm trying to do something similar here. Although the linked issue is probably the best solution, I think it'll be more difficult to implement as there probably would be performance drawbacks. Simply passing typeof type, where type would be a string (in case of intrinsic elements) or the symbol of the value-based component (function/class) to JSX.Element as a type parameter, would cover most use cases.