Intellisense should show internals of an interface declaration on hover

[mjsarfatti]

Search Terms

• intellisense interface
• intellisense interface expand

Suggestion

I'm trying to re-open and start a discussion around #32616 and #12920, which were closed as "working as intended". It may well be the case, but it would be useful if Interfaces were expanded by default just as Type Aliases are.

Is there a hard reason impeding this I'm not seeing?

What are the metrics saying that "in general interfaces are longer"? Today Interfaces and Type Aliases offer almost the same features and they are for the most part interchangeable (especially for typing objects, see: https://stackoverflow.com/a/52682220/416714)

I understand there is a discussion around expandable hints (#25784). Would that be the occasion to bring expanded-by-default Interfaces?

Examples

When hovering over a Type:

When hovering over an Interface:

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

There are still many more open questions around how to display an interface vs a type alias. For example, for something like this

interface Base {
  x: string;
}
interface Derived1<T> extends Base {
  y: T;
}
interface Derived2 extends Derived1<string> { }

what's the "right" hover for Derived2? There are many good answers possible and you can construct types arguing for each of them but it's not easy to devise "consistent" rules around which should be shown when.

[mjsarfatti]

I believe the "right" hover is the one that gives the best information to the developer as he/she is trying to implement it.

This is how the equivalent in type alias is hinted:

type Base = {
  x: string;
}

type Derived1<T> = Base & { y: T }

type Derived2 = Derived1<string> & { flag: boolean }

Since interfaces and type aliases are 99% feature-equivalent, I would by default give to interfaces the same treatment as type aliases, if technically possible.

[pramodkandel]

Any update on this? I have been using interfaces in my project because of some of their additional features over types, but just because of hovers not showing the description, I'm tempted to use the types. Is there any activity on implementing/not implementing this request?

[jhillert-dmg]

This is driving me crazy. In fact, it's such a deal-breaker I've stopped writing interfaces altogether, and am leaning towards flat types free of unions and intersections, any time I can get away with it.

Typescript is supposed to be all about the self-documenting, among other things. When I hover a symbol, I expect to get useful information about the symbol. If the hint just mirrors back at me the symbol I'm already looking at, plus the word "interface", what am I getting out of that? I already know it's either a type or an interface. The only reason I would hover my cursor over an interface is to see the internals without disrupting my flow.

The alternatives are just not as good. Peek and GoTo tend to disrupt my concentration. File switching and pressing keys to escape out of a peek are distracting. And code completion is great when you already know where you are going and want to get there faster (Although I do use it more and more as a discovery tool). But when I have a problem, and I'm trying to understand what's going on, hover is the best, most unobtrusive means for getting what I need to know without having to navigate around.

Where no interface info really hurts is in react and component-based workflow. For example, I am currently writing a common component for my company's platform.For better or worse it needs a lot of props. I can't avoid it. I want the component to explain itself to my colleagues, and to make it clean and easy for them to use, some nesting of props is needed. Now if I use a huge flat type, they get all that info at a glance. But once I start combining types, or nesting, I lose some of that. And if I use an interface I lose all of it except the JsDocI add myself.

Final point, from what I can tell, a lot of devs don't know the code completion shortcut for vs code and are not going to see the available props. It's not like JetBrains where every backender has those kinds of shortcuts on speed dial. But even my parents know that putting a cursor over something will call up information about it. Currently, hovering Interfaces provides no value. M would be really great to at least provide some configuration options so cvs code users can enable accessing this information by hover.

---

Clarification: The above rant shouldn't be taken to mean I don't appreciate you guys. I love vs code. It's great and it keeps getting greater. Just this one thing is a recurring issue. I keep looking for something I expect to be there and it's never there.

[rewrking]

Just wanted to chime in on this topic because "type vs interface" comes up every now and then, and it occurred to me over the weekend that this was the main reason why I've preferred type for a few years now. I can lazily mouse over most types and see their properties.

I'm also aware that interface is supposedly more performant to the typescript compiler and that's the reason why it's preferred, but at least to me, the trade-off isn't worth it, because tooling with interface isn't the same.

So that leaves the question: Why can't it be the same? There's clearly room for improvement in this area, and it could result in a huge win.

[ivo2666]

You need to hold ctrl when hovering over the interface and you will see the description.
https://stackoverflow.com/questions/61851075/typescript-extending-interfaces-and-hover-hints

[rewrking]

Right, but why the extra step with interface, when you don't need to do that with type?

[basickarl]

Ironic that Microsoft is in charge of both TypeScript development and VSCode. This should be addressed.

[marcelo-agil]

You need to hold ctrl when hovering over the interface and you will see the description. https://stackoverflow.com/questions/61851075/typescript-extending-interfaces-and-hover-hints

But won't display all properties, there's no scroll or any other thing that can display the entire interface.

If you right click, you can peek the entire interface, but its not practical.

[justindoordash]

Isn't this an obstacle based on the nature of interfaces? Since interfaces can be inherited there's possibly a dev tooling architectural decision they've made not to drill in to interfaces for properties as it could lead to a large number of iterations for deeply extended types. Not a deal breaker as one could set a max levels sort of thing. But I get why types show all properties out of the box bc they are non-extendable and thus more likely to have flat properties. That being said there's no reason we couldn't get what we do when we're looking at a union type, maybe like this:

interface BirdInterface {
  wings: 2;
}

// NOTE: intellisense would just preview this shape
interface Parrot extends BirdInterface {
  name: string
}

[LutherTS]

I'm just learning about interfaces (and about TypeScript altogether) and I think I can say that from a student's standpoint, not seeing their combined definitions on hover is a dealbreaker from using them. I think it will take me quite some time to reach a project where they're that unavoidable – though it's great to know about them in teams that do use them, such as in my training.
I can guess that since it's not really static data the way types are, perhaps there would need to be some extra computing every time a hover is made. But I think this computing can be done every time the project is saved in VS Code so that the hover would show the state of the interface at the time of saving, or that it needs saving to be actualized. Still, if Typescript can instantly show errors once the interface is updated in coding, I don't see why its combined definitions can't be updated at the same time on hover.