Description

Dan Quirk (danquirk)

opened on Sep 5, 2014

Issue body actions

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.

Reacted by Olmo del Corral, Noel Abrahams, Taylor Brown and SlurpTheo

Activity

1. Dan Quirk (danquirk)

   added

   Suggestion

   on Sep 5, 2014
2. mhegazy commented on Sep 5, 2014

   

   Mohamed Hegazy (mhegazy)

   on Sep 5, 2014

   Contributor

   More actions

   +1
3. DanielRosenwasser commented on Sep 5, 2014

   

   Daniel Rosenwasser (DanielRosenwasser)

   on Sep 5, 2014

   Member

   More actions

   👍 would potentially like to take this on.
4. RyanCavanaugh commented on Sep 5, 2014

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Sep 5, 2014

   Member

   More actions

   To consider: is this an editor-side feature or a language service feature?
5. DanielRosenwasser commented on Sep 5, 2014

   

   Daniel Rosenwasser (DanielRosenwasser)

   on Sep 5, 2014

   Member

   More actions

   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.
6. mhegazy commented on Sep 5, 2014

   

   Mohamed Hegazy (mhegazy)

   on Sep 5, 2014

   Contributor

   More actions

   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.
7. danquirk commented on Sep 5, 2014

   

   Dan Quirk (danquirk)

   on Sep 5, 2014

   MemberAuthor

   More actions

   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).
8. jbondc commented on Sep 25, 2015

   

   Jon (jbondc)

   on Sep 25, 2015

   Contributor

   More actions

   👍 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
9. DanielRosenwasser commented on Nov 11, 2015

   

   Daniel Rosenwasser (DanielRosenwasser)

   on Nov 11, 2015

   Member

   More actions

   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.
10. Daniel Rosenwasser (DanielRosenwasser)

    added

    Domain: Literal TypesUnit types including string literal types, numeric literal types, Boolean literals, null, undefinedUnit types including string literal types, numeric literal types, Boolean literals, null, undefined

    on Mar 9, 2016
11. mrcrowl commented on Mar 9, 2016

    

    mrcrowl

    on Mar 9, 2016

    More actions

    +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!
12. NoelAbrahams commented on Apr 15, 2016

    

    Noel Abrahams (NoelAbrahams)

    on Apr 15, 2016

    More actions

    👍 .

    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' | ...;
13. Daniel Rosenwasser (DanielRosenwasser)

    closed this as completedin #8125on Apr 18, 2016
14. danquirk commented on Apr 18, 2016

    

    Dan Quirk (danquirk)

    on Apr 18, 2016

    MemberAuthor

    More actions

    Daniel Rosenwasser (@DanielRosenwasser) is this really fixed? #8125 looks like it fixes the enum issue Jon (@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.

    Reacted by Daniel Rosenwasser
15. Daniel Rosenwasser (DanielRosenwasser)

    reopened this on Apr 27, 2016
16. DanielRosenwasser commented on Apr 27, 2016

    

    Daniel Rosenwasser (DanielRosenwasser)

    on Apr 27, 2016

    Member

    More actions

    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. 😄
17. Mohamed Hegazy (mhegazy)

    closed this as completedin #8428on Jun 8, 2016
18. Mohamed Hegazy (mhegazy)

    added

    FixedA PR has been merged for this issueA PR has been merged for this issue

    on Jun 8, 2016
19. Mohamed Hegazy (mhegazy)

    added this to the TypeScript 2.0 milestone on Jun 8, 2016
20. danquirk commented on Jun 9, 2016

    

    Dan Quirk (danquirk)

    on Jun 9, 2016

    MemberAuthor

    More actions

    Mohamed Hegazy (@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?
21. microsoft

    locked and limited conversation to collaborators on Jun 18, 2018

Issue actions