VS Code to autocomplete JavaScript class 'this' properties automatically (react-etc.net)

this is great. But seriously, this is my setup for 75% of my work, Visual Studio Code with JS, excited to see this little feature in action.

I was blown away how well VSC interacts with JS, especially autocompletion via imports.

Can someone explain why this (can't stop those puns) is a big deal?

1. I mean why hasn't it existed before? Surely an editor can figure out which object you're in and auto-complete this on the basis of that.

2. If it is hard for some reason, how did they do it?

    function example() { console.log(this.v); };

    example.apply({ v: 'One' })
    example.apply({ v: 'Two' })

    class ExampleClass {
        example() { console.log(this.v); }
    }

    const e = new ExampleClass();
    e.example.apply({ v: 'One' });
    e.example.apply({ v: 'Two' });

    'this' implicitly has type 'any' because it does not have a type annotation.

    function example(this: { v: string }) { console.log(this.v); };

    example.apply({ b: 3 })

    Function.apply(this: Function, thisArg: any, argArray?: any): any

Is this new feature specific to vanilla JS classes? I've been using autocomplete for Typescript classes in VS Code for as far back as I can remember.

I don't think this title is correct.

`this` is the receiver of the function, which can change depending on how the function is invoked, scope, etc.

The feature does not know the type of "this".

It doesn't complete "this." but rather when you type a member variable it inserts "this.member". ex. type "width" and it replaces it with "this.width".

Not to be a grump, but if you were using a staticly-typed language with any half-baked IDE 20 years ago, this behavior was available.

The most important word in the title is "class". It only does this properly for JS code inside an explicit ES6 class, and, after some cursory testing, doesn't work too well if you bind things to the class at runtime/outside of the main class block.

VS code doesn't autocomplete "this" for "old-school" (function-provided "this" objects and manual prototype inheritance etc.) object-orientish JS; it doesn't compute it properly or at all for re-bound "this" (e.g. apply()/bind()).

Making autocompletion analysis work for non-straightforward non-ES6 OO javascript is a very hard (maybe impossible even without any "eval"ed code, though I'm not sure) thing to do, so this isn't a ding on VS code: any autocompletion is better than none.

That said, if the only way to get good OO-code autocompletion is to reduce the subset of the language/OO models usable to basically "what you could have in Java/C#", it might be a good opportunity to re-evaluate your choice of language. Transpilers for more easily-statically-analyzable languages do exist, after all.

How does this compare to Webstorm's autocomplete functionality (as it's one of the primary reasons I started using WS years ago)?

Madness. Code is so much cleaner when developers drop "this" from their code.

VS Code JavaScript/Typescript extension dev here

Yes this feature is completely obvious in hindsight, so much so that I felt a little silly highlighting that we never did it before. I guess sometimes you just need someone to file a feature request to point this type of thing out

Anyways, please try it out in the current VS Code insiders builds and VS Code 1.20 once it is released next week. Lots of much more exciting stuff coming in 1.20 as well

By itself this isn't very impressive, but there's more context in the wings if you pay careful attention to the TypeScript type system. Take a look at https://github.com/Microsoft/TypeScript/pull/21316 and https://github.com/Microsoft/TypeScript/pull/21496. This, combined with the existing literal types and mapped types, allows the TypeScript compiler to understand a huge set of existing practices in the JavaScript world, and do high quality type inference over code that looks totally untypable.

For example, this is a pattern I see a lot:

  const args = parseCliFlags({
    help: {
      parser: Boolean,
      description: 'whether to show help',
      short: 'h',
    },
    custom: {
      parser: (v: string) => {return {hmmm: 'yes'}},
      repeated: true
    }
  });
  if (args.help) {
    console.log('help screen!');
  }
  for (const custom of args.custom) {
    console.log(custom.hmmm);
  }

So we produce an args object based on the descriptors passed into parseCliFlags. Specifically, we use the parser function and the repeated field. With the above PRs, this code can be fully type checked:

  interface Descriptor {
    readonly parser: (value: string) => any;
    readonly description?: string;
    readonly short?: string;
    readonly repeated?: true;
  }
  interface Descriptors {
    readonly [flag: string]: Descriptor;
  }
  type FlagTypes<T> = { [K in keyof T]: FlagTypeOf<T[K]> };
  type ReturnTypeOf<V> = V extends (...args: any[])=>infer R ? R : never;
  type FlagTypeOf<V> = V extends {repeated: true, parser: (val: string)=> infer R} ? R[] : V extends {parser: (val: string)=> infer R} ? R : never;

That code is tricky to write, but it only needs to be written once, and submitted to DefinitelyTyped. From that point, every VSCode user could benefit from these typings (they already have this part working today, with typings for your node libraries downloaded automatically from DefinitelyTyped).

Perhaps unrelated, but JavaScript has the most annoying handling of "this" in classes that I've ever seen.

I'm constantly typing "bind(this)", while the default case should be that "this" within a class points to the object.

I understand backward compatibility, but I wish there was some command I could add at the beginning of the file to make JS behave normally. Kind of like "use strict".