Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Expandable Quick Info/Hover Verbosity #59029

Open
DanielRosenwasser opened this issue Jun 26, 2024 · 7 comments
Open

Support Expandable Quick Info/Hover Verbosity #59029

DanielRosenwasser opened this issue Jun 26, 2024 · 7 comments
Assignees
Labels
Domain: Quick Info e.g. hover text, tool-tips, and tooltips. Domain: Type Display Bugs relating to showing types in Quick Info/Tooltips, Signature Help, or Completion Info

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 26, 2024

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 DanielRosenwasser added Domain: Type Display Bugs relating to showing types in Quick Info/Tooltips, Signature Help, or Completion Info Domain: Quick Info e.g. hover text, tool-tips, and tooltips. labels Jun 26, 2024
@DanielRosenwasser DanielRosenwasser added this to the TypeScript 5.6.0 milestone Jun 26, 2024
@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Jun 26, 2024

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
Copy link
Member

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

@starball5
Copy link

Related on Stack Overflow:

@evelant
Copy link

evelant commented Sep 10, 2024

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
Copy link

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
Copy link
Member

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Domain: Quick Info e.g. hover text, tool-tips, and tooltips. Domain: Type Display Bugs relating to showing types in Quick Info/Tooltips, Signature Help, or Completion Info
Projects
None yet
Development

No branches or pull requests

6 participants