How can I send params from a VS Code extension to my Analysis server plugin?

[Max Tamburini]

Hello,

I'm trying to create an anaysis server plugin and I would like to pass some parameters to it from a VS Code extension.

Let's take the "Extract Widget" or "Extract Method" quick fixes of the Dart-Code extension as an example: both are implemented into the Analysis Server but before being executed the VS Code extension asks for a widget/method name (the code can be found in the Dart-Code repo in src\extension\analysis\analyzer_lsp.ts file).

So I was thinking about creating an extension for VS Code where I can handle this input before running the task, but will it work? Because the language server connection is handled by Dart-Code extension and unfortunately VS Code doesn't have a listener to react before running the command (however you can listen after the execution).

Is it possible to implement it somehow?

[Brian Wilkerson]

--
You received this message because you are subscribed to the Google Groups "Dart Analyzer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to analyzer-discu...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/analyzer-discuss/2d631b3d-f08d-4f03-b301-e59da8eb94e7n%40dartlang.org.

[Danny Tuppeny]

I don't think there's any reasonable way to implement this today. The way those refactorings currently prompt for names is a bit of a workaround for LSP not having any way to request user input (there's an open issue about this here). It relies on the VS Code extension having some specific knowledge of the refactors.

Although it might be possible to find a way that another VS Code extension could interact with this, my understanding is that the current set of refactorings in the server is fixed and cannot be contributed to by analyzer plugins. Fixes and assists can be contributed, but they don't support parameters and just produce a fixed set of edits.

Can you provide an example of the sort of refactor you were hoping to implement and what sort of input it requires from the user? 

[Max Tamburini]

Sure,

I would like to create some useful quick fixes related to functional_widget package. 

A quick fix example could be "Extract To Functional Widget" where you can execute it when cursor is over a Widget (very similar to "Extract Widget").

It should move the widget and its content into a new function like this, adding every params required:

@swidget

Widget functionName(BuildContext context, int value) {

  return Text('$value');

}

And it should place the function name where there was the widget before.

Why I need params?

I can use them to customize the generated output:

• Instead of 'functionName', I can prompt the user for the name to insert or put 'functionName' as default if nothing is passed (and I have seen that is the current behavior with Extract Widget).
• I can also ask the user which decorator to write (@swidget, @hwidget, @hcwidget, @hwidget). However, I'm still thinking of putting it in my VS Code extension settings, where you can choose the default decorator to use and if set, skip the decorator request during the quick fix execution. In fact, I could take my VS Code extension settings and use them during this process to customize the output, such as "always add key param to the function" or "prefer arrow functions" (I know, these are trivial things).

As I said, there's no OnWillExecuteCommand in VS Code, but there's onDidExecuteCommand: maybe I can do something after the command execution, however I don't think it's a great way to do it.

[Max Tamburini]

Sure,

I would like to create some useful quick fixes related to functional_widget package. 

A quick fix example could be "Extract To Functional Widget" where you can execute it when cursor is over a Widget (very similar to "Extract Widget").

It should move the widget and its content into a new function like this, adding every params required:

@swidget

Widget functionName(BuildContext context, int value) {

  return Text('$value');

}

And it should place the function name where there was the widget before.

Why I need params?

I can use them to customize the generated output:

• Instead of 'functionName', I can prompt the user for the name to insert or put 'functionName' as default if nothing is passed (and I have seen that is the current behavior with Extract Widget).
• I can also ask the user which decorator to write (@swidget, @hwidget, @hcwidget, @hwidget). However, I'm still thinking of putting it in my VS Code extension settings, where you can choose the default decorator to use and if set, skip the decorator request during the quick fix execution. In fact, I could take my VS Code extension settings and use them during this process to customize the output, such as "always add key param to the function" or "prefer arrow functions" (I know, these are trivial things).

As I said, there's no OnWillExecuteCommand in VS Code, but there's onDidExecuteCommand: maybe I can do something after the command execution, however I don't think it's a great way to do it.

Il giorno mercoledì 13 luglio 2022 alle 21:58:22 UTC+2 da...@tuppeny.com ha scritto:

[Danny Tuppeny]

Thanks for the extra info.

> As I said, there's no OnWillExecuteCommand in VS Code, but there's onDidExecuteCommand

I don't think a hook like this would be enough. Assuming you could prompt the user for some input, I can't see a way for you get that input to your plugin on the server. The existing "Extract ..." refactors are server "Refactorings" (not assists or fixes) and are executed by calling the servers "refactor.perform" command. This command is only able to execute specific refactors that are known to the server (see switch statement here) and not any plugin code.

I believe that supporting something like this via server plugins will require new server/plugin APIs (in addition to some work in the client editor).

[Max Tamburini]

Understood.

Anyway thanks for your help. I can see there's a not inconsiderable amount of work.

If you want to support it in the future I'll be glad to help.

[Max Tamburini]

One last question: apart from parameters, is it possible to implement new ways of refactoring? Should I use quick fixes? I think not, because these aren't errors (text shouldn't be underlined).

[Danny Tuppeny]

You probably want to look at assists. They're similar to quick fixes, but they don't require an error to be reported to use them.

[Max Tamburini]

Okay, thank you