GeezerVison is showing github.com — Enable method signature completions for object literal that is implementing an interface · Issue #46590 · microsoft/TypeScript
Enable method signature completions for object literal that is implementing an interface #46590DescriptionBug 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 {
}
}Reacted by Andrew Branch, Oleksandr Tarasiuk, Gabriela Araujo Britto, Daniel Rosenwasser, Dave Houlbrooke, Rhee Jung In, Jayden Pearse, stefnotch, David Luzar, Emmanuel Chucks 🇬🇭 and 2 more Activityandrewbranch commented on Oct 29, 2021 This was a known limitation of the PR for 4.5, but probably won't be difficult to add in 4.6. a-tarasyuk commented on Nov 11, 2021 Andrew Branch (@andrewbranch) Should the completion of object literal elements be allowed with the includeCompletionsWithClassMemberSnippets option, or should a new option be added? andrewbranch commented on Nov 11, 2021 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? Reacted by Gabriela Araujo Britto and Diyawan mjbvz commented on Nov 12, 2021 ContributorAuthor More actions 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 Reacted by Gabriela Araujo Britto and sanitysign mjbvz commented on Nov 12, 2021 ContributorAuthor More actions Let's make sure we decide on on this before 4.5 goes so I can rename the VS Code setting if needed andrewbranch commented on Nov 12, 2021 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.*. Reacted by Gabriela Araujo Britto andrewbranch commented on Nov 12, 2021 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 commented on Nov 15, 2021
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).
andrewbranch commented on Nov 15, 2021
we'd want to separately enable completions for objects vs classes
Agreed. And you’re right, there are other significant differences. Parameters are contextually typed in object literals so there’s no need to write their type annotations. Also, in a class member position you can be fairly sure that a user starting to type a method name intends to type a whole method declaration. Not so in object literals, where it is possible to write a property assignment to an existing function instead:
import * as ts from "typescript";
const host: ts.LanguageServiceHost = {
fileExis/*|*/
};At this location we have no heuristics that would indicate whether the user intends to write a function literal / method declaration or a property assignment:
const host: ts.LanguageServiceHost = {
fileExists: ts.sys.fileExists,
};so we cannot replace the completion containing just the fileExists name. We would need to offer both options, and the two completion items need to be easy to disambiguate in the list. We need to be careful that users don’t find themselves automatically getting whole method declarations when they meant to only get a property name. It sounds like this feature needs a bit of careful UX design work. Reacted by Gabriela Araujo Britto and Michael Borislav starball5 commented on Mar 18, 2024
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
