Enable method signature completions for object literal that is implementing an interface

[mjbvz]

Bug Report

🔎 Search Terms

• Method signature completions
• suggest / suggestions
• completions

🕗 Version & Regression Information

4.5.0-dev.20211029

💻 Code

For the code:

interface IFoo {
    bar(x: number): void;
}

const obj: IFoo = {
    |
}

Trigger suggestions inside the object literal

🙁 Actual behavior

We get a suggestion for bar but accepting it only completes bar

🙂 Expected behavior

Accepting the completion for bar should also insert the method signature:

interface IFoo {
    bar(x: number): void;
}

const obj: IFoo = {
    bar(x: number): void {
        
    }
}

[andrewbranch]

This was a known limitation of the PR for 4.5, but probably won't be difficult to add in 4.6.

[a-tarasyuk]

Andrew Branch (@andrewbranch) Should the completion of object literal elements be allowed with the includeCompletionsWithClassMemberSnippets option, or should a new option be added?

[andrewbranch]

Gabriela Araujo Britto (@gabritto) and I briefly discussed this when coming up with the name at the time. IIRC we didn’t really feel great about any options and mostly just lamented that we don’t have a way of presenting hierarchical preferences. One related thought is that for object literals we might want to give an option for whether to always use arrow function properties or to match the declaring interface—I personally tend to use arrow functions for object literal members even when the member is written as a method signature on the interface. If we do want to make that configurable, I think we would need a separate option. Gabriela Araujo Britto (@gabritto) Daniel Rosenwasser (@DanielRosenwasser) Matt Bierner (@mjbvz) what do you think?

[mjbvz]

Andrew Branch (@andrewbranch) I think we can surface these settings sort of hierarchically in VS Code if we want. Right now have

javascript.suggest.includeCompletionsWithClassMemberSnippets

but we could expand this to something like:

javascript.suggest.classMemberSnippets.enabled
javascript.suggest.classMemberSnippets.methodStyle: "arrow"

We'd keep two distinct settings on the TS side, this would just be for the VS Code settings UI

[mjbvz]

Let's make sure we decide on on this before 4.5 goes so I can rename the VS Code setting if needed

[andrewbranch]

Matt Bierner (@mjbvz) that only affects the presentation of the setting title in the UI, right?

This is better than nothing, but it still appears as a flat list and is kind of hard to navigate. But, properly organizing the data leaves room for UI improvements later. I like your suggestion for the setting name, though I’m now having stronger doubts about using the term “class” to control something for object literals as well. Maybe at that point we can do javascript.suggest.objectMemberSnippets.*.

[andrewbranch]

I think that change wouldn’t require any changes on the TS side right now; the new name can still map to the existing TS preference name.

[gabritto]

Andrew Branch (@andrewbranch) I think we can surface these settings sort of hierarchically in VS Code if we want. Right now have

javascript.suggest.includeCompletionsWithClassMemberSnippets

but we could expand this to something like:

javascript.suggest.classMemberSnippets.enabled
javascript.suggest.classMemberSnippets.methodStyle: "arrow"

We'd keep two distinct settings on the TS side, this would just be for the VS Code settings UI

I agree with Andrew Branch (@andrewbranch), I think this is better than what we have now, but I think we want to have something more structured for these options in the future.

Also, a few other things on my mind:

• Not sure if it's relevant or if it's just a personal nit, but I'm still concerned that there's a javascript option when we don't yet support this feature in JS and don't have concrete plans for it (yet -- I opened an issue: Support class member snippet completions in JS files #46738).
• This is just an intuition for now, but I sense it's likely we'd want to separately enable completions for objects vs classes. They are similar scenarios at first glance, but the differences tend to add up quickly. For instance, the arrow vs function preference Andrew Branch (@andrewbranch) brought up, but also there might be type inference edge cases for objects that are not there for classes, and completions for class properties is easier to deal with than for object properties (which inevitably brings up the question of what value to assign to the property in the completion, or to put an empty placeholder).
  I might be wrong though. And if we'd like to have structured/hierarchical settings for this in the future, I could imagine something like suggest.methods and grouped under that, suggest.methods.classes and suggest.methods.objects (illustrative names).