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

Better handlng of hyphenated properties #4032

Closed
chocolatechipui opened this issue Jul 26, 2015 · 17 comments
Closed

Better handlng of hyphenated properties #4032

chocolatechipui opened this issue Jul 26, 2015 · 17 comments
Labels
API Relates to the public API for TypeScript Help Wanted You can do this Suggestion An idea for TypeScript
Milestone

Comments

@chocolatechipui
Copy link

It is common in JavaScript to have hyphenated property names. For example:

var obj = {
   "foo-bar" : "Foo Bar"
};

The property "foo-bar" can be accessed like so:

obj["foo-bar"] \\ returns "Foo Bar"

From my use of TypeScript I've noticed that when using these in code or interfaces, TypeScript does not seem to reveal them as possible values. I'm talking about Intellisense, code completion, etc. I've noticed that when examining these types of properties in the Safari Web inspector, that it is aware these properties exist on the object. When you type obj[ it will pop up all the possible object properties including the hypenated ones.

I would hope it would be possible to reveal hyphenated object properties to the end user so that they can get completion for these types of hyphenated properties.

Here is an example of a recent ambient declaration I wrote:

interface fetch {
    (input: string, init?: {
      method?: {
        delete?: string, 
        get?: string, 
        head?: string, 
        options?: string, 
        post?: string, 
        put?: string
      },
      headers?: {
        Accept?: string;
        "Accept-Language"?: string;
        "Content-Language"?: string;
        "Content-Type"?: {
          "text/plain"?: string;
          "application/x-www-form-urlencoded"?: string;
          "multipart/form-data"?: string;
        }
      },
      body?: any;
    }): Promise<any>;
}

When the user types:

fetch('a/b/c/d', {
   headers: {
   }
});

Only the value Accept gets revealed, the other hyphenated values are ignored. Trying to use bracket notation does not work.

@mhegazy
Copy link
Contributor

mhegazy commented Jul 26, 2015

That is a missing feature in the language service API. The assumption is that you will call getCompletions after a dot, something that is hyphenated is not valid after a dot; what we need to do is for get completions to return a substitution string, i.e. a.| => a["accept-language"].

@mhegazy mhegazy added Suggestion An idea for TypeScript API Relates to the public API for TypeScript Help Wanted You can do this labels Jul 26, 2015
@mhegazy
Copy link
Contributor

mhegazy commented Jul 26, 2015

We would be open to take a PR for this if you are interested.

@chocolatechipui
Copy link
Author

I'm assuming that's in tsserver.js. From looking at that method, it appears that the real one of interest is getCompletionsAtPosition, which is server/client.ts. I don't see any documentation regarding the internal workings, not even comments. At least some types are there. Is there any documentation for tsserver.js?

@danquirk
Copy link
Member

There's some amount of documentation in the wiki in the same section as this page: https://github.com/Microsoft/TypeScript/wiki/Architectural-Overview

@mhegazy
Copy link
Contributor

mhegazy commented Jul 27, 2015

one thing to note here, is we need to do this in a way that is backward compatible, i.e. editor using the services today would not need ot make changes (or just minimum if at all).

@bawr
Copy link

bawr commented Jul 30, 2015

This issue is of particular interest to me as well. I wouldn't mind working on it over the weekend, but I have one question first, since my Google-fu failed, and I don't want to break my TSC setup just yet. ;)

When I make my changes and I want to test them in Visual Studio, is it enough to overwrite the typescriptServices.ts file in the ..\CommonExtensions\Microsoft\TypeScript directory with my new generated version, or is the process more involved?

@DanielRosenwasser
Copy link
Member

@bawr I would use Dev mode and have your language service file point to the one in your built/local folder instead, though, if you build with errors, your language service might crash (#4084 fixes this).

See https://github.com/Microsoft/TypeScript/wiki/Dev-Mode-in-Visual-Studio

@bawr
Copy link

bawr commented Jul 30, 2015

Sweet!

I actually browsed through the wiki, but I neglected to look at the page listing after scrolling down, heh.

@DanielRosenwasser
Copy link
Member

Is this a duplicate of #606?

@mhegazy
Copy link
Contributor

mhegazy commented Sep 29, 2015

it is related, #606 is mainly about specialized signatures.

@DanielRosenwasser
Copy link
Member

Okay, now that specialized signatures are just a weird special case of using string literal types, is this a duplicate of #606?

@mhegazy
Copy link
Contributor

mhegazy commented Apr 20, 2016

it is related but not a duplicate.

@mhegazy mhegazy added this to the Community milestone Jan 4, 2018
@RyanCavanaugh RyanCavanaugh modified the milestones: Community, Backlog Mar 7, 2019
@matt-subroot
Copy link

How are hyphenated properties handled now? Stuck on this today. Thanks!

@fuafa
Copy link
Contributor

fuafa commented Jul 31, 2019

Seems this is fixed already

@matt-subroot
Copy link

Can you please provide an example of syntax or a link to such syntax?

@fuafa
Copy link
Contributor

fuafa commented Jul 31, 2019

image

Trigger suggestion inside headers.

@RyanCavanaugh
Copy link
Member

Works now, though note that this requires a compliant language service host that can handle non-insertive completions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Relates to the public API for TypeScript Help Wanted You can do this Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

8 participants