Provide completion lists for string literals

[danquirk]

Many JavaScript frameworks are heavily based on using string values to do many things, from getting and setting attributes via the property name in string form, to defining event handlers to handle browsing to particular URLs. TypeScript added specialized signatures in overloads as one means to help mitigate the pain associated with these types of APIs. Unfortunately for a number of patterns this is insufficient and not general enough. Rather than try to design a specific type system enhancement that could handle some or all of the many ways these frameworks use string literals we could try some simple tricks in Visual Studio to help out. Namely, when typing a string literal the editor should provide a completion list based on other string literals already used in your program. Some other tools already provide similar capabilities (ex Sublime Text).

Consider something like this in a Backbone View class:

class TodoView extends Backbone.View<TodoModel> {
    initialize() {
        this.listenTo(this.model, 'change', () => this.render());
        this.listenTo(this.model, 'todoDescriptionChanged', () => this.render());
        this.listenTo(this.model, 'destory', () => this.remove());
    }

At another point I may attempt to manually trigger one of these events:

    updateTodo() {
        var desc = this.$input.val().trim();
        var todo = this.model;
        if (desc) {
            todo.save({ title: desc });
            // provide completion list inside this string literal showing 
            // todoDescriptionChanged to avoid hard to debug typos 
            // and speed up development
            todo.trigger('todoDescriptionChanged'); 
        }
     }

This should be a relatively cheap solution to a common set of problems that we've always hoped TypeScript can improve on over JavaScript. If you did accidentally make a typo in one use of the literal this could also help you discover that when seeing 2 completion list items that are similar but slightly different.

[mhegazy]

+1

[DanielRosenwasser]

👍 would potentially like to take this on.

[RyanCavanaugh]

To consider: is this an editor-side feature or a language service feature?

[DanielRosenwasser]

While it seems like it should be editor-side, I'd argue that's hard to generalize because of languages with multi-line string literals, and languages like TS/JS that have single-quote string literals. So to answer your question, I'm not actually sure.

[mhegazy]

The change is mainly on the services layer. we need to provide completions within strings, something we disallow today. there is a small change on the editor side to include strings in legal locations to ask for completions, but that should be trivial.

[danquirk]

It's entirely possible this should be an general editor feature where a language service can opt into the set of tokens that would provide completions within strings. For example C# might want this feature but only using other string literals for completion suggestions. TypeScript and JavaScript language services may want a larger view of completion options in string literals that also considers other tokens like class method names (ex consider writing a handler for a Backbone route and then going back to the routes object literal and needing to add that method name in string form).

[jbondc]

👍 Related is enums:

Likely two improvements (applied to interfaces too):

• Member/prop names of string literals should show up a list["a"] = 0
• Autocomplete works on string literals

[DanielRosenwasser]

Now that string literal types are a thing in the compiler, this will become more useful.

Additionally, much like object literal completions are informed by its contextual type, we should consider doing the same with string literal completions. For instance:

type T = "foo" | "bar";

let x: T = "$

At $, I expect my completions to be only "foo" and "bar", regardless of any other identifiers in the file.

[mrcrowl]

+1 please! Just to give you a user's point of view... I had assumed this would be included when string literals were released. But regardless would love to see this done when you guys are able!

[NoelAbrahams]

👍 .

I hope this goes in soon as it will be quite useful.

Also JSDoc should be supported for the values:

    /** Defines the permissible size measures. */
    export type SizeRule =

        /** Indicates the smallest possible size */
        'tiny' |

        'small' | ...;

[danquirk]

@DanielRosenwasser is this really fixed? #8125 looks like it fixes the enum issue @jbondc mentioned in #606 (comment) but all the tests in that PR look enum related. This issue is really a broader suggestion around string literal values outside of the type system.

[DanielRosenwasser]

GitHub is not good at auto-closing if you just refer to fixing a comment (in that it totally shouldn't be doing that). Thanks for the heads up Dan. 😄

[danquirk]

@mhegazy It doesn't look to me like #8428 addresses the example in the original suggestion. The compiler now gives type directed string literal suggestions but it doesn't just generally supply previously used string literals as completion options (like Sublime Text and other text editors do). Is that right?