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

Intellisense should show internals of an interface declaration on hover #38040

Open
5 tasks done
mjsarfatti opened this issue Apr 18, 2020 · 19 comments
Open
5 tasks done
Assignees
Labels
Domain: Quick Info e.g. hover text, tool-tips, and tooltips. Experimentation Needed Someone needs to try this out to see what happens In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@mjsarfatti
Copy link

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:

Screenshot 2020-04-18 at 15 44 41

When hovering over an Interface:

Screenshot 2020-04-18 at 15 45 01

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 RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Apr 20, 2020
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Apr 20, 2020

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

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:

Screenshot 2020-04-29 at 11 00 07

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

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

jhillert-dmg commented Apr 17, 2022

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

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

ivo2666 commented Nov 4, 2022

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

rewrking commented Nov 4, 2022

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

@basickarl
Copy link

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

@marcelo-agil
Copy link

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

justindoordash commented Jun 14, 2023

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

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.

@starball5
Copy link

Related on Stack Overflow: TypeScript interface doesn't show its properties in VS Code hover widget or on ctrl-k-i.

@Ryan-Zayne
Copy link

@mjsarfatti Sorry this might be unrelated to the ongoing discussion but what font and theme do you have going on there?
I find it too aesthetic not to ask👀

@brillout
Copy link

brillout commented Oct 6, 2023

Related feature request: #56010.

si-bors-ng bot added a commit to systeminit/si that referenced this issue Oct 10, 2023
2841: feat: change interfaces to types for quickinfo r=sprutton1 a=sprutton1

Same as described [here](microsoft/TypeScript#38040), the Typescript system does not extract deep information from `interface`s, so if we want the details on the hover/hotkey, we need them to be `type`s.

I have no idea what implications this might have elsewhere, so insight there would be good. Everything seems good in my tests still.

Co-authored-by: Scott Prutton <sprutton1@gmail.com>
@FrancoRATOVOSON
Copy link

Issue opened in 2020, we're 2024 now, how's this going team ?

@jamesheazlewood
Copy link

I'm wondering if there an issue with interfaces because of declaration merging? eg. you can do this:

interface Foo { 
    name: string; 
}

interface Foo {
    age: number;
}

interface Foo {
    subscribed: boolean;
}

const fooObject: Foo = {
    name: 'John Smith',
    age: 41,
    subscribed: true
}

But types don't have this feature. Hovering over Foo in VS Code will show interface Foo, and ctrl/cmd + hover will show interface Foo Click to show 3 definitions.. What would be the expected behaviour for this situation?

@arienshibani
Copy link

Any progress here? Or should we just keep using types?

@starball5
Copy link

@arienshibani microsoft/vscode#195394

@warpigroadkill
Copy link

I'm having the same issue when using TypeScript and creating a new Interface Object, I used to be able to tab into the curly braces and it would should the intellisense listing as the properties that I needed to provide/have access to etc. However, doesn't effect the running of my applications, just the workflow I use.

@DanielRosenwasser DanielRosenwasser added In Discussion Not yet reached consensus Experimentation Needed Someone needs to try this out to see what happens and removed Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Jun 25, 2024
@DanielRosenwasser DanielRosenwasser added this to the TypeScript 5.6.0 milestone Jun 25, 2024
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. Experimentation Needed Someone needs to try this out to see what happens In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests