Closed
Description
Specify Acceptable JSX Tags with JSX.ElementType
Menu
can't restrict its children toMenuItem
s because<JSXTags>
always returnsJSX.Element
.- Tried to fix this - huge perf and compat issues.
- Why are we revisiting?
- Alternative approach with RFC: Consult new JSX.ElementType for valid JSX element types #51328
- Motivated by RFC: First class support for promises and async/await reactjs/rfcs#229 and the notion that component functions can by
async
now (i.e. they return aPromise<...>
).- But you don't want every
JSX.Element
to possibly be a function! The framework wants to just allow the tags to be async.
- But you don't want every
- Will this work for class components/
render
methods?- Unclear from the proposal.
ElementType
specifies what the type of a tag can be.- Seems reasonable overall? Some questions though.
- Why does it need generics?
- Why can't we modify
JSXElementConstructor
?- Try that offline.
- Two concepts
-
What can functions used as tags return?
JSX.Element
-
What type can tags have?
JSX.Renderable
-
import * as React from "react"; function Foo(): JSX.Renderable { return "hello!"; } // What type can tags have? - JSX.Renderable(?) // What can functions used as tags return? - JSX.Element // () => string assignable to () => JSX.Element const element = <Foo />; // ^? const divTag = <div /> // ^?
-
- Conclusion: not opposed. We do want some more clarity on:
- Could React we get away with just modifying
React.JSXElementConstructor
? - Why is the type parameter required?
- Could React we get away with just modifying
Too Many Types!
- Lots of avenues for performance improvements.
- But we have a Turing-complete type system.
- Horrendously expensive types - you usually discover this when statement completion is slow.
- We get the blame for a lot of these, but you can write arbitrary amounts of work!
- Yes we should speed up the type system
- But as we speed things up, that affords people with the ability to write slow types.
- Example of induced demand (e.g. building roads doesn't reduce traffic - it incentivizes drivers).
- How do we bring awareness to where the complex types come from?
- Today the only thing we do is say "instantiation was deep and possibly infinite."
- Kind of a panic button for us.
- Can we give something like an earlier error/warning of "huh, this seems risky"?
- Maybe we need some sort of opt-in to say "I don't care".
- There are TSServer events - we can possibly provide a pop-up to warn people when a library is causing a lot of type instantiations.
- We can point out expensive statements, but we can't point to the type that is being instantiated a lot.
- User code looks innocent, the library is the thing doing a lot of the work.
- We already have the "panic button" error - is that good enough today, or is the location of the error too confusing?
- [[Editor's Note]]: users often report that it is too confusing.
- Recent example was some code with a "visitor" that tries to capture and operate on lots of types.
- tsserver and intellisense hang indefinitely on "loading intellisense status" and "loading..." when using assertion function and complex conditional type #51188
- Caused the language service to hang.
- Sometimes instantiations are spread out and the "panic error" was not consistently issued.
- How do we help library authors know that they're writing slow types?
- Tests for libraries (e.g. on DefinitelyTyped) are often shallow unit-testy use-cases, not complete real-world examples.
- Some of the "bananas" types that we see are people trying to achieve explainable things.
- Good example - people want a function call to infer as if the user had always written
as const
so they write recursive conditional types. - But they don't want users to have to write
as const
.
- Good example - people want a function call to infer as if the user had always written
- What about overlaying the things that are "expensive" in the editor as an experimental feature? Like a heatmap?
- What does it measure? Type instantiation? Not a perfect measure.
- But it's something!
- What does it measure? Type instantiation? Not a perfect measure.
- No conclusion, but some avenues to explore.