Repository navigation
Suggestion: Refactor extract to type alias/typedef #23869
Description
Activity
it's very helpful to me
Wenlu Wang (@Kingwl) is that something you would be interested to implement as well? we would accept a PR for this one.
Reacted by Wenlu Wangsure，but it going to be late，my deadline is coming😂
something need to consider:
- option parameter?
- rest parameter?
- update all
CallExpression?
- For optional parameters I would strip off the
|undefinedfrom 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 betype 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.Reacted by Wenlu Wang- For optional parameters I would strip off the
Yes, I confused the two feature (:sad) , this one looks like this is a relatively simple operation
could you give some advice about the new name of the newType?
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.
should it trigger with signal primitive type and extract to a type alias?
I suppose so.. any type node really should be extractable..
Wenlu Wang (@Kingwl) we were just wishing we had this 😉
Reacted by Wenlu WangI'll on it😂
Reacted by Andy WilliamsThe 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:
FunctionNameOptionsORClassNameMethodNameOptions.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 likeParams,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.
Reacted by Andy Williams and SlurpTheoThanks Wenlu Wang (@Kingwl)!
TypeScript Version: 2.9.0-dev.201xxxxx
Search Terms: Refactor, extract type, typedef
In a TypeScript file
Extract to type alias:would generate:
In a JavaScript file
Extract to typedef:would generate:
gif courtesy of Daniel Rosenwasser (@DanielRosenwasser)