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

Provide completion lists for string literals #606

Closed
danquirk opened this issue Sep 5, 2014 · 13 comments
Closed

Provide completion lists for string literals #606

danquirk opened this issue Sep 5, 2014 · 13 comments
Labels
Domain: Literal Types Unit types including string literal types, numeric literal types, Boolean literals, null, undefined Fixed A PR has been merged for this issue Suggestion An idea for TypeScript Visual Studio Integration with Visual Studio

Comments

@danquirk
Copy link
Member

danquirk commented Sep 5, 2014

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

mhegazy commented Sep 5, 2014

+1

@DanielRosenwasser
Copy link
Member

👍 would potentially like to take this on.

@RyanCavanaugh
Copy link
Member

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

@DanielRosenwasser
Copy link
Member

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

mhegazy commented Sep 5, 2014

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

danquirk commented Sep 5, 2014

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

jbondc commented Sep 25, 2015

👍 Related is enums:

image

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

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.

@DanielRosenwasser DanielRosenwasser added the Domain: Literal Types Unit types including string literal types, numeric literal types, Boolean literals, null, undefined label Mar 9, 2016
@mrcrowl
Copy link

mrcrowl commented Mar 9, 2016

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

👍 .

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

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

DanielRosenwasser commented Apr 27, 2016

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. 😄

@mhegazy mhegazy added the Fixed A PR has been merged for this issue label Jun 8, 2016
@mhegazy mhegazy added this to the TypeScript 2.0 milestone Jun 8, 2016
@danquirk
Copy link
Member Author

danquirk commented Jun 9, 2016

@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?

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Domain: Literal Types Unit types including string literal types, numeric literal types, Boolean literals, null, undefined Fixed A PR has been merged for this issue Suggestion An idea for TypeScript Visual Studio Integration with Visual Studio
Projects
None yet
Development

No branches or pull requests

7 participants