Typescript: [Proposal] Display all properties (inherited or not) of a given class (in TypeScript)

[waderyan]

_From @yahiko00 on September 4, 2016 21:56_

Visual Studio Code is a fantastic tool and I am really impressed by all its features despite being quite young.

There is a feature that does not still exists in VS Code which could be really convenient when we are forced to deal with big inheritance hierarchies.

This proposal is based on the TypeScript language, but I am quite sure this could apply to other OOP languages VS Code supports.

Overview of the Workflow

Let us assume we have a source file _animal.ts_ like this:

// animal.ts

abstract class Animal {
    private dna: number;
    name: string;

    constructor(name: string) {
        this.dna = Math.random();
        this.name = name;
    }

    abstract shout(): string;
}

This file could be open or not in VS Code, but it is part of the current project.

Let us assume we have another source file _bird.ts_ like this:

// bird.ts

class Bird extends Animal {
    constructor() {
        super();
        this.name = "Hector";
    }
    shout(): string {
        return "Cuicui!"; // sorry it is in French... I do not know how a bird shouts in English ^_^
    }
}

This file is open in VS Code.

What I would like to be able to do in VS Code is displaying all properties, inherited or not, available for the class Bird.

To do so, we could move the cursor on the Bird identifier, press F1 key, and run a new _Display all inherited properties_ command.

This new command would open a new file in a new tab called _Bird (all inherited properties)_.

In this example, the content of this file would be the following:

class Bird {
    private dna: number;
    name: string;

    super.constructor(name: string) {
        this.dna = Math.random();
        this.name = name;
    }

    constructor() {
        super();
        this.name = "Hector";
    }

    shout(): string {
        return "Cuicui!";
    }
}

The content of _Bird (all inherited properties)_ has nothing to do with valid syntax. Its purpose is only informational.

Some informal rules

• Attributes should be displayed first.
• Type anotations should be rendered unchanged.
• Access modifiers public, protected, private should be rendered unchanged.
• Abstract methods which are not overriden should be rendered.
• All versions of an overriden method should be rendered, with a concatenation of super prefixes to distinguish each version in the inheritance hierarchy. For instance super.method() would refer to immediate method()'s parent, whereas super.super.method() would refer to method()'s grand-parent, and so on.
• Method()'s parent should be displayed before the method() itself.
• The same rules for method() apply to constructor().

_Copied from original issue: Microsoft/vscode#11526_

[waderyan]

@dbaeumer this request seems valid to me. Is this something I should feed to TypeScript or is this a feature we would implement on our end (possibly both)?

[waderyan]

_From @dbaeumer on September 7, 2016 8:36_

@waderyan this needs work on both ends. First the tsserver has to expose a corresponding API and then we need to adopt it. So we need to feed the request to the TS team as well.

[mhegazy]

How this different from completion with this. or new Bird().?

[waderyan]

Ping @yahiko00

[yahiko00]

Well, I am not an expert of TS Services, but I would say completion could help to retrieve property names and signatures (which is nice already), but I am unsure completion would help to retrieve actual code content of methods.

[mhegazy]

but I am unsure completion would help to retrieve actual code content of methods

not sure i understand what you mean by that.

[waderyan]

@yahiko00, @mhegazy's question is, are you not already getting all inherited properties provided by IntelliSense with this.?

[yahiko00]

@waderyan @mhegazy IntelliSense with this. does provide all inherited properties, names and signatures. In fact, when I was thinking about my proposal, I had autocompletion in mind.
However, autocompletion/IntelliSense does not provide methods' body (what is inside brackets), unless I am mistaken. Method bodies are useful to reason about a class without navigating through all its ancestors. This where my proposal comes into place.

Also, using autocompletion as a mean to _discover_ a class has the drawback to modify the current code.

The purpose of my proposal is to help reasoning, debugging and documenting the code in _read-only_ mode.

[mhegazy]

@waderyan and @dbaeumer i will let you decide what is the best experience here, and then give us a specific requirements for the tsserver command you need.

[yahiko00]

@waderyan and @dbaeumer If more formal description is needed on my side for this proposal, just let me know.

[yahiko00]

I have just stumbled upon an issue where IntelliSense has been no help.

// classA.ts
class A {
    method() {
        // ...
    }
}

// classB.ts
class B {
    method() {
        // Overriding without super call
    }
}

IntelliSense is not able to tell me that B.method() overrides A.method().
With a complete overview of class B, with the content of its inherited methods as described in this proposal, I would be able to see that my implementation method() in class B could be incorrect.

[pocesar]

I was going to open an issue and found this one. I have an use case that I ALWAYS seem to stumble upon. Take React for example:

class MyComponent extends React.Component<Props, State> {
   /* if I press Ctrl + Space here, I won't get the React.Component method 
       for overloading, like componentWillMount, componentDidMount, etc (they are defined 
       in ComponentLifecycle, and defined as 
       `class Component<P, S> implements ComponentLifecycle<P, S>`  
   */
   render() {
     // for example, the methods from React.Component doesn't exist in this.
     // note that this shouldn't be done (componentWillMount shouldn't be called manually)
     // just putting it here so demonstrate
    this.componentWillMount() // shows "Property "componentWillMount" does not exist on type MyComponent 
   } 
}

[mhegazy]

@pocesar this should be working as intended now:

[pocesar]

yeah I noticed this as well in newer vscode versions (since I use nightlies with it)

[BrainMaxx]

I was searching for the same functionality and came up with the own extension you mught take a look at https://marketplace.visualstudio.com/items?itemName=MaxGotovkin.tslens

Feedback appriciated