You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
import*asReactfrom"react";functionFoo(): JSX.Renderable{return"hello!";}// What type can tags have? - JSX.Renderable(?)// What can functions used as tags return? - JSX.Element// () => string assignable to () => JSX.Elementconstelement=<Foo/>;
// ^?constdivTag=<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?
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.
Specify Acceptable JSX Tags with
JSX.ElementType
#51328
Menu
can't restrict its children toMenuItem
s because<JSXTags>
always returnsJSX.Element
.async
now (i.e. they return aPromise<...>
).JSX.Element
to possibly be a function! The framework wants to just allow the tags to be async.render
methods?ElementType
specifies what the type of a tag can be.JSXElementConstructor
?What can functions used as tags return?
JSX.Element
What type can tags have?
JSX.Renderable
Playground Example
React.JSXElementConstructor
?Too Many Types!
as const
so they write recursive conditional types.as const
.The text was updated successfully, but these errors were encountered: