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
This is because we flatten union types out to "normalize" them.
This means that that there's no "a" | "b" | "c" union whose type can be tied back to T.
This PR ensures that we track the "origin" node before the types get normalized/flattened so that we can display these correctly.
Also other work: when we end up normalizing intersections of union types, we'll preserve the original structure of the written type for display.
All this means that we can do a little extra work to display things better, more consistently, avoid unrelated aliasing.
This manifests itself in the language service; hover over an alias before a direct usage of a union, and vice versa, and you'll get consistent results.
typeT="a"|"b"|"c";// won't display as 'T', regardless of whether// you hover over T first.letx: "a"|"b"|"c";
So we'll do better at displaying the type that you wrote!
We also do this for keyof types now as well; we'll preserve keyofs.
Super useful for code which maps over every possible property, where you really DON'T want to have a union of 1000 literals.
Is there a cost to this?
Yes, we do we a bit of work being done.
This is a little bit unfortunate because you can't really expand these out.
We do something with literal types and fresh types - is there a similar approach we could use here?
As of 3 days ago, we started caching relations between unions, and we have other heuristics - so that's part of why the perf isn't too bad.
Does it make sense to have a first-class alias type internally?
Would generalize the aliasing logic farther than unions and keyof.
Can imagine some editor UI to give the alternative representation to avoid opaque type display.
Conclusion: looks good - let's get it in.
The text was updated successfully, but these errors were encountered:
Abstract Constructor Types
#36392
abstract
constructor types to theInstanceType
helper type in a follow-up release.Function & { prototype: T }
.abstract
?abstract class
, there are some intractable problems.private
/protected
.abstract
.typeof class { ... }
would ideally work better.abstract
on instance sides? Seems odd that you need to declare a class to get anabstract
instance side.Preserved Origin Types for Unions and Intersections
#42149
Very common issue where people have an alias like
Oops!
This is because we flatten union types out to "normalize" them.
This means that that there's no
"a" | "b" | "c"
union whose type can be tied back toT
.This PR ensures that we track the "origin" node before the types get normalized/flattened so that we can display these correctly.
Also other work: when we end up normalizing intersections of union types, we'll preserve the original structure of the written type for display.
All this means that we can do a little extra work to display things better, more consistently, avoid unrelated aliasing.
This manifests itself in the language service; hover over an alias before a direct usage of a union, and vice versa, and you'll get consistent results.
So we'll do better at displaying the type that you wrote!
We also do this for
keyof
types now as well; we'll preservekeyof
s.Is there a cost to this?
This is a little bit unfortunate because you can't really expand these out.
We do something with literal types and fresh types - is there a similar approach we could use here?
As of 3 days ago, we started caching relations between unions, and we have other heuristics - so that's part of why the perf isn't too bad.
Does it make sense to have a first-class alias type internally?
keyof
.Can imagine some editor UI to give the alternative representation to avoid opaque type display.
Conclusion: looks good - let's get it in.
The text was updated successfully, but these errors were encountered: