TypeScript icon indicating copy to clipboard operation
TypeScript copied to clipboard

Support Expandable Quick Info/Hover Verbosity

Open DanielRosenwasser opened this issue 1 year ago • 11 comments

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 https://github.com/microsoft/vscode/issues/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 avatar Jun 26 '24 00:06 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
    },
}

DanielRosenwasser avatar Jun 26 '24 00:06 DanielRosenwasser

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

weswigham avatar Jul 08 '24 17:07 weswigham

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.

evelant avatar Sep 10 '24 13:09 evelant

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 avatar Sep 25 '24 10:09 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.

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

gabritto avatar Sep 25 '24 17:09 gabritto

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

florianbepunkt avatar Sep 27 '24 08:09 florianbepunkt

According to VS Code version 1.96 release notes, this feature should be available via a settings flag as long as you have TS 5.8 or later. But I'm not able to see it in VS Code 1.98.0 running TS 5.8.2, and with "typescript.experimental.expandableHover": true. I'm still not seeing types fully expanded, nor am I seeing the +/- to expand. Expected?

Image Image Image Image

justingrant avatar Mar 08 '25 20:03 justingrant

This was backed out in https://github.com/microsoft/TypeScript/pull/61132.

jakebailey avatar Mar 08 '25 20:03 jakebailey

According to VS Code version 1.96 release notes, this feature should be available via a settings flag as long as you have TS 5.8 or later. But I'm not able to see it in VS Code 1.98.0 running TS 5.8.2, and with "typescript.experimental.expandableHover": true. I'm still not seeing types fully expanded, nor am I seeing the +/- to expand. Expected?

Image Image Image Image

Yes not working on my side

mamlzy avatar Mar 17 '25 04:03 mamlzy

This was backed out in #61132.

@mamlzy Did you read the post directly above yours that explains that it was removed? Which sort of makes your post irrelevant noise to this thread?

0xdevalias avatar Mar 17 '25 08:03 0xdevalias