Skip to content

A way to expand mapped types #28508

Open
Open

Description

@mmis1000

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

2018-11-13 12 33 16

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

type Mapper<T> = {
    [K in keyof T]: 
        T[K] extends {type: SQL_ENUM<infer U>}? U:
        T[K] extends {type: SQL_ENUM<infer U>, allowNull: true}? U | undefined:
        
        T[K] extends {type: typeof Sequelize.DATE, allowNull: true}? Date | undefined:
        T[K] extends {type: typeof Sequelize.DATE}? Date:

        T[K] extends {type: typeof Sequelize.INTEGER, allowNull: true}? number | undefined:
        T[K] extends {type: typeof Sequelize.INTEGER}? number:

        // stop here, fon't let things goes too wrong
        T[K] extends {type: typeof Sequelize.ENUM}? never:

        T[K] extends {type: typeof Sequelize.STRING, allowNull: true}? string | undefined:
        T[K] extends {type: typeof Sequelize.STRING}? string:

        T[K] extends {type: typeof Sequelize.TEXT, allowNull: true}? string | undefined:
        T[K] extends {type: typeof Sequelize.TEXT}? string:

        T[K] extends {type: typeof Sequelize.BOOLEAN, allowNull: true}? boolean | undefined:
        T[K] extends {type: typeof Sequelize.BOOLEAN}? boolean:

        any
}

that will transform the decalration to a simple

interface session {
    token: string,
    userId: string,
    ip: string
}

But the ide won't tell you anything, which is quite annoying

Activity

  1. weswigham commented on Nov 13, 2018

    @weswigham
    Member

    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:

    1. 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.

    2. 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.

    3. 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.

    4. 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.

    cc Daniel Rosenwasser (@DanielRosenwasser) and Ryan Cavanaugh (@RyanCavanaugh) since I think we've mentioned this before.

  2. removed their assignment
    on Nov 6, 2019
  3. jantimon commented on Nov 6, 2019

    @jantimon

    This might look like the expand feature as described in #34944?

    Typescript

  4. akutruff commented on Feb 9, 2021

    @akutruff

    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

    const Person: t.TsTypeToObjType<MapPropDefinitionsToTsTypes<MapPropDefinitionsToTsOptionalProperties<t.MapTsPropertiesToPropDefinitions<MapPropDefinitionsToTsTypes<MapPropDefinitionsToTsOptionalProperties<MapObjectDefParamsToPropDefinitions<{
        type: t.Type<"string">;
    }>>> & MapPropDefinitionsToTsTypes<...>, never>>> & MapPropDefinitionsToTsTypes<...>>
    type Person = {
        type: LiteralType<"Person">;
        name: Type<"string">;
        age: Type<"number">;
    }
  5. dragomirtitian commented on Feb 9, 2021

    @dragomirtitian
    Contributor

    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} } ).

  6. akutruff commented on Feb 9, 2021

    @akutruff

    Titian Cernicova-Dragomir (@dragomirtitian)

    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)

    type Id<T> = T extends object ? {} & { [P in keyof T]: Id<T[P]> } : T;
  7. martaver commented on Sep 19, 2021

    @martaver

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    In DiscussionNot yet reached consensusSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions