Support Expandable Quick Info/Hover Verbosity

[DanielRosenwasser]

There is a lot of interest and discussion in #38040 and #56010 when it comes to showing/hiding details of a quick info request. In microsoft/vscode#195394, we have a proposed client/editor API to serve up such an experience, and we'd like to provide it.

There are some questions that still need to be answered and prototyped. For example, what precisely should be expanded? In some cases, a type reference can be expanded into its structural form. In others, an elision (...) can possibly be shown. Whether this is always desirable is questionable.

[DanielRosenwasser]

Moving this out of the issue body, since this is more of my own suggestion than a spec.

A good experience here may need some clever thinking. Some parts of quick info which a user may want to expand may be totally unrelated to what actually gets expanded out.

One possible direction here is to expand in a breadth-first way instead of depth-first. For example, if a user sees the following type:

/* Verbosity 0 */
{
    foo: Foo,
    bar: Bar,
    baz: Baz,
}

expanding on a depth-first basis might pop everything out in the following way

/* Verbosity 0 */
{
    foo: Foo,
    bar: Bar,
    baz: Baz,
}

/* Verbosity 1 */
{
    foo: {
        fooProp: string
    },
    bar: {
        barProp: string
    },
    baz {
        bazProp: string
    },
}

whereas allowing expansion on a breadth-first level might be a little less daunting, albeit more tedious:

/* Verbosity 0 */
{
    foo: Foo,
    bar: Bar,
    baz: Baz,
}

/* Verbosity 1 */
{
    foo: {
        fooProp: string
    },
    bar: Bar,
    baz: Baz,
}

/* Verbosity 2 */
{
    foo: {
        fooProp: string
    },
    bar: {
        barProp: string
    },
    baz: Baz,
}

/* Verbosity 3 */
{
    foo: {
        fooProp: string
    },
    bar: {
        barProp: string
    },
    baz {
        bazProp: string
    },
}

[weswigham]

Ref #31384 which previously experimented with instrumenting diagnostic message construction to allow expandable spans like this.

[starball5]

Related on Stack Overflow:

• How to see a fully-expanded TypeScript type without "N more" and "..."?
• (duplicate?) How to view full type definition on hover in VSCode, TypeScript?
• (duplicate) How can I make VS Code show full TypeScript type definitions on mouse hover?

[evelant]

At least in my experience and opinion this is the number 1 pain point with TS. Many times a day (or even hour) I run into situations where TS is truncating the useful parts of a type or error.

[florianbepunkt]

Would this also include the other way around? I have complex inferred types that I would like to collapse, because more often than not the type signature is longer than what VS code shows me.

[gabritto]

Would this also include the other way around? I have complex inferred types that I would like to collapse, because more often than not the type signature is longer than what VS code shows me.

@florianbepunkt I'm not sure I understand precisely what you mean by "collapse" here, could you provide an example?

[florianbepunkt]

@gabritto

Sure. For example we have an event sourcing system that uses the functional Effect lib. Works pretty well, but given a type of Invoice with lots of props, I get this type signature in VS code on hover:

Effect.Effect<State<{
    readonly createdAt: Date;
    readonly currency: "EUR" | "USD";
    readonly items: readonly {
        readonly _id: string;
        readonly description: string;
        readonly title: string;
        readonly exportMeta?: {
            readonly channelId: string;
            readonly exportId: string;
            readonly period: {
                ...;
            };
            readonly requestedAt: Date;
        } | undefined;
        readonly qty: number;
        readonly total: number;
        readonly unitPrice: number;
    }[];
    ... 9 more ...;
    readonly status: "draft";
} | {
    ...;
}>, AggregateNotFoundError | ... 8 more ... | ParseError, Decider.ExecutionEnvironment.InMemory | InvoiceRepository>

What would be great is to drill in and out of types. In the example above, I would like to collapse the the State<{...}> part, so it shows an ellipse or something else and instead extend the ... 8 more ... part at the end of the type signature.