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.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Andarist commentedon Oct 28, 2022
Please tell me that the solution to this is coming 🙏 😜 5.0 is just around the corner, just saying... 😉
mihailik commentedon Dec 4, 2022
What's needed is a tool that will map type system delays onto text.
Load file(s) — get a map.
Plug it into the Playground, VSCode maybe. But key is to capture metrics.
Will help investigate issues too, of course.