Decouple jsx element type from jsx factory return type and sfc return type
See original GitHub issueWe need to look up the type of a jsx expression by actually resolving the jsx factory call, so that we don’t create a reference to the global JSX.Element
type, which can change shape between react versions (as it needs to in the react 16 upgrade). We also need to resolve the sfc return type and class element type from the parameters of the factory function overloads for the same reasons, doubly so because the types allowable as render
method and SFC
return values are no longer the same as JSX.Element
(namely, they can be strings, arrays, portals, etc).
This might be considered a breaking change, because some consumers may expect JSX.Element
to always be a supertype of both jsx element expression return types and SFC return types (even though this isn’t true in react 16) - we certainly made that assumption internally, hence the need for the change. 🐱
Issue Analytics
- State:
- Created 6 years ago
- Reactions:372
- Comments:72 (28 by maintainers)
Top GitHub Comments
Based on the above mentions of this issue, several other issues across react are waiting for resolution on this. Is this on the roadmap to be resolved? Any updates that can be provided for the many folks watching?
Whatever solutions come out of this, please TS team don’t make it React-specific in any way.
The ecosystem is always morphing, and React is merely but an alternative to other libraries and frameworks that also have JSX syntax that work in unique ways, and we don’t know if React will always be the most used component system around.
I don’t know how it should be implemented, but it should be possible to have the following be possible at some point (for example using the variant of JSX currently found in the Solid.js component system):
where the type of
div
is correctly inferred to beHTMLDivElement
,comp
is inferred to beHTMLParagraphElement
, andapp
inferred to be the tuple[HTMLSpanElement, HTMLDivElement, HTMLParagraphElement]
.