Suggestion: Refactor extract to type alias/typedef

[mhegazy]

TypeScript Version: 2.9.0-dev.201xxxxx

Search Terms: Refactor, extract type, typedef

In a TypeScript file Extract to type alias:

var x: { a: number, b: string } = { .. };

would generate:

type newType = { a: number, b: string }
var x: newType = { .. };

In a JavaScript file Extract to typedef:

/** @type {import("./c2").mytype} */
var x;

would generate:

/** @typedef {import("./c2").mytype} newType */

/**@type {myType} */
var x;

gif courtesy of @DanielRosenwasser

[Kingwl]

it's very helpful to me

[mhegazy]

@Kingwl is that something you would be interested to implement as well? we would accept a PR for this one.

[Kingwl]

sure，but it going to be late，my deadline is coming😂

[Kingwl]

something need to consider:

1. option parameter?
2. rest parameter?
3. update all CallExpression ?

[mhegazy]

• For optional parameters I would strip off the |undefined from the type e.g. function f(a? :number | undefined) => type newType = number ; function f(a?: newType)
• initializers need to be maintained, e.g. function f(a : number | string = 0) should be type newType = number | string; function f(a: newType = 0)
• rest parameters are fine, since you are extracting their type
• do not think you need to update call expressions..

I think you are confusing this feature with extract to named arguments. e.g. function f(a: number, b:string) => function f({a, b}: {a: number, b:string}). this one is tracked by #23552.

[Kingwl]

Yes, I confused the two feature (:sad) , this one looks like this is a relatively simple operation

[Kingwl]

could you give some advice about the new name of the newType?

[mhegazy]

dose not matter what name you pick really. it has to be unique. The new name will be the rename location for the refactoring, and thus the user will get to update it immateriality after the refactor is applied.

[Kingwl]

should it trigger with signal primitive type and extract to a type alias?

[mhegazy]

I suppose so.. any type node really should be extractable..

[RyanCavanaugh]

@Kingwl we were just wishing we had this 😉

[Kingwl]

I'll on it😂

[mattwelke]

The 3.4 release notes mention this issue for providing feedback about this feature were they to expand it to create a type for the new parameter object.

I feel like a nice convention would to be to tap into the name of the function and its class if the function is a method to arrive at the following convention: FunctionNameOptions OR ClassNameMethodNameOptions.

Example:

Before refactor:

class Foo {
    bar(a: string, b: number) {
      console.log('bar');
    }
}

Refactored:

interface FooBarOptions {
    a: string;
    b: number;
}

class Foo {
    bar(o: FooBarOptions) {
        console.log('bar');
    }
}

Instead of Options, the suffix could also be things like Params, Args, etc. Whatever the community thinks makes the most sense.

The parameters interface would be placed in the same file because it would make sense for another module to import this module in order to reference its types and use its functions. The developer could move the interface into another file if they wanted to.

[DanielRosenwasser]

Thanks @Kingwl!