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
I want to be able to expand mapped type in intellisense
Currently, mapped types is displayed directly with the mapper and original type, which is unhelpful as hell
With the ts 2.8 condition type,
you can write more powerful declaration to map almost everything to correct type for you,
but the ide simply show it is mapped,
you don't know what is it actually mapped to.
for example, in the above case, I have a mapper looks like
Matt Bierner (@mjbvz) could we perhaps expose consider exposing clickable "expando" ranges in quick info/signature help that fire a request to a new language server endpoint with a token associated with the range for expanded content for the range (and that expanded content may itself have more things which need expansion)? Off the top of my head, I can think of four places where this'd be useful:
Generics, aliases, and type queries. Click the a type reference to replace it with the structural decomposition (or conditional, union, whatever the underlying structure is) of the reference.
The any or ... we print for reverse mapped types. These types are limited in how much we print, as they have each property inferred on demand (as they each need to be mapped backwards through a mapped type). This is what happens when, for example, we infer the T in a Readonly<T> - we need to undo the readonlyness on whatever we find for T and we do that in a deferred fashion (since otherwise a circular type reference in the T would blow up, as we have no good name for our unmapped T to reference with). Being able to expand these one property at a time in the editor as needed would be great.
The any or ... we print on encountering circular referential local types. This happens when, for example, you have two mutually recursive functions that return one another. We actually type check this strongly, but both will just print as () => () => any or () => () => ... (as of yesterday) today, since we have no reference that we know will stick around with which to indicate the circularity.
The ... we print in the output when the type is truncated for being too long. Sometimes, even when a type is truncated, the part you care about isn't in the beginning bit and you just wanna see more. Turning on noErrorTruncation works, but then you might always get huge types (and commensurately longer LS response times) - being able to expand little bits on demand could be a boon here.
This might look like the expand feature as described in #34944?
Reacted by Alan North, Johnson Liang, Joe Edelman, Arnau Sanchez Sala, Andy Kutruff, kezhi wang, Aaron Cowie, Rishabh Rao, Tom Stordy-Allison, Egor Andreyuk and 6 more
I just ran into this myself setting up similar code. I have a lot of conditional and mapped types that work wonderfully, but they unfortunately render intellisense unusable.
Andy Kutruff (@akutruff) You can use an Id type to expand out the properties of a type alias (type Id<T> = {} & { [P in keyof T]: T[P} } ).
Thanks for the suggestion. Unfortunately that didn't solve the problem. Only one property became simplified, but otherwise, it still has expanded noise.
Edit: From your suggestion, I was able to find another thread #22575 (comment) with a similar approach. In my case, I have recursive types, and that was causing the issue! Here is a modified version that does trick, but it runs into the issue with potentially infinite recursion. #34933 (comment)
I believe most of the pain in intellisense with regards to mapped types is because they're often passed inferred types that have no better name than their expanded form. Ordinarily, Typescript should display a type alias's name wherever possible, e.g. Mapped<Person>, however if Person has any logic to it, TS will instead display the fully expanded type, even if the 'Person' alias is explicitly passed.
There's also currently no way in Typescript to provide a name for an inferred type.
If the above problem were fixed and we were able to name inferred types, then we would be able to architect types whose naming actually communicates intent to developers clearly. I believe these would also provide natural points in intellisense where a developer could opt to 'step into' type expansion.
I detail the problem and make a proposal for new syntax to name inferred types here: #45954
Activity
weswigham commentedon Nov 13, 2018
Matt Bierner (@mjbvz) could we perhaps expose consider exposing clickable "expando" ranges in quick info/signature help that fire a request to a new language server endpoint with a token associated with the range for expanded content for the range (and that expanded content may itself have more things which need expansion)? Off the top of my head, I can think of four places where this'd be useful:
Generics, aliases, and type queries. Click the a type reference to replace it with the structural decomposition (or conditional, union, whatever the underlying structure is) of the reference.
The
anyor...we print for reverse mapped types. These types are limited in how much we print, as they have each property inferred on demand (as they each need to be mapped backwards through a mapped type). This is what happens when, for example, we infer theTin aReadonly<T>- we need to undo the readonlyness on whatever we find forTand we do that in a deferred fashion (since otherwise a circular type reference in theTwould blow up, as we have no good name for our unmappedTto reference with). Being able to expand these one property at a time in the editor as needed would be great.The
anyor...we print on encountering circular referential local types. This happens when, for example, you have two mutually recursive functions that return one another. We actually type check this strongly, but both will just print as() => () => anyor() => () => ...(as of yesterday) today, since we have no reference that we know will stick around with which to indicate the circularity.The
...we print in the output when the type is truncated for being too long. Sometimes, even when a type is truncated, the part you care about isn't in the beginning bit and you just wanna see more. Turning onnoErrorTruncationworks, but then you might always get huge types (and commensurately longer LS response times) - being able to expand little bits on demand could be a boon here.cc Daniel Rosenwasser (@DanielRosenwasser) and Ryan Cavanaugh (@RyanCavanaugh) since I think we've mentioned this before.
jantimon commentedon Nov 6, 2019
This might look like the expand feature as described in #34944?
akutruff commentedon Feb 9, 2021
I just ran into this myself setting up similar code. I have a lot of conditional and mapped types that work wonderfully, but they unfortunately render intellisense unusable.
Intellisense
dragomirtitian commentedon Feb 9, 2021
Andy Kutruff (@akutruff) You can use an
Idtype to expand out the properties of a type alias (type Id<T> = {} & { [P in keyof T]: T[P} }).akutruff commentedon Feb 9, 2021
Titian Cernicova-Dragomir (@dragomirtitian)
Thanks for the suggestion. Unfortunately that didn't solve the problem. Only one property became simplified, but otherwise, it still has expanded noise.
Edit: From your suggestion, I was able to find another thread #22575 (comment) with a similar approach. In my case, I have recursive types, and that was causing the issue! Here is a modified version that does trick, but it runs into the issue with potentially infinite recursion. #34933 (comment)
martaver commentedon Sep 19, 2021
I believe most of the pain in intellisense with regards to mapped types is because they're often passed inferred types that have no better name than their expanded form. Ordinarily, Typescript should display a type alias's name wherever possible, e.g.
Mapped<Person>, however ifPersonhas any logic to it, TS will instead display the fully expanded type, even if the 'Person' alias is explicitly passed.There's also currently no way in Typescript to provide a name for an inferred type.
If the above problem were fixed and we were able to name inferred types, then we would be able to architect types whose naming actually communicates intent to developers clearly. I believe these would also provide natural points in intellisense where a developer could opt to 'step into' type expansion.
I detail the problem and make a proposal for new syntax to name inferred types here:
#45954