Description

Oliver Joseph Ash (OliverJAsh)

opened on Jun 11, 2019

Issue body actions

Search Terms

function expression declaration extract method refactoring code fixes

Suggestion

"Extract to function" is very useful, but it only supports generating function declarations. Some people (such as me) prefer to use function expressions instead of declarations.

For example:

const fn = () => {
    const foo = 1;
    const bar = foo + 2
}

If I select line 3 and extract to function, I get

const fn = () => {
    const foo = 1;
    const bar = newFunction(foo)
}

function newFunction(foo: number) {
    return foo + 2;
}

I want:

const newFunction = (foo: number) => foo + 2;

const fn = () => {
    const foo = 1;
    const bar = newFunction(foo)
}

Some ideas:

• An option to toggle between expressions/declarations
• Separate refactorings for both expressions and declarations

Use Cases

Examples

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this featureThis means we'd like to hear from more people who would be helped by this feature

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   on Jun 17, 2019
2. ypresto commented on Aug 4, 2019

   

   Yuya Tanaka (ypresto)

   on Aug 4, 2019

   Contributor

   More actions

   For me:

   • Inner (not-top-level) function?
     • Yes: const clickHandler = (e: Event) => { ... }
     • No: Need to annotate with predefined function type?
       • Yes: const Component: React.FC = () => { ... }
       • No: function someExpensiveLogic() { ... }
3. ypresto commented on Aug 4, 2019

   

   Yuya Tanaka (ypresto)

   on Aug 4, 2019

   Contributor

   More actions

   I'm afraid that too many choices of refactoring would be shown.

   I prefer arrow function for inner function, as it's this binding is just for that. (Currently function declaration is generated.)

   For top level functions, I vote on function declaration. But it might be helpful to have "convert to arrow function" refactoring.
4. OliverJAsh commented on Jun 30, 2020

   

   Oliver Joseph Ash (OliverJAsh)

   on Jun 30, 2020

   ContributorAuthor

   More actions

   But it might be helpful to have "convert to arrow function" refactoring.

   Here's a start nicoespeon/abracadabra#114
5. OliverJAsh commented on Dec 29, 2020

   

   Oliver Joseph Ash (OliverJAsh)

   on Dec 29, 2020

   ContributorAuthor

   More actions

   This idea also applies to the forthcoming "declare function" code fix: #41215. That is, we need a way to let users choose what type of function they want TS to create for them: an expression or a declaration. /cc Oleksandr Tarasiuk (@a-tarasyuk)

   Reacted by Oleksandr Tarasiuk

Issue actions