VS Razor Code Actions

[TanayParikh]

Summary of the changes

• Razor Code Actions support for Add Using + Fully Qualified Namespace for Tags
  • 
• Extract to Component & Create Component should just work, however haven't had a chance to test them out yet as the create document commands aren't currently available directly.
• Support for both VS + VS Code Code Actions
• Added/updated tests
• Note seeing this sometimes: https://github.com/dotnet/aspnetcore/issues/25105
  • Background document is "correct"
  • Investigating still

Fixes: https://github.com/dotnet/aspnetcore/issues/23985

[NTaylorMullen]

Love how the preview is available for a lot of the code actions. I'd reach out to the LSP platform team to see why they didn't provide the "preview" support for edits that were already available on the CodeAction

[NTaylorMullen]

Looks solid! Exactly how I was thinking it'd fit together. Man it's exciting to see this land 👏

[ajaybhargavb]

Looks great! Mostly minor comments
Also, would be good to make sure the changes here didn't accidentally regress VSCode.

[TanayParikh]

Updated with PR feedback.

@NTaylorMullen suggested removing the existing razor/runCodeAction entirely to simplify the flow and minimize the endpoints we need to maintain. Made the appropriate changes there. 😄

Also, would be good to make sure the changes here didn't accidentally regress VSCode.

Yep, validated all four in VSCode 💯

[NTaylorMullen]

Ahhh one other note I forgot to mention that can totally be done in a follow up. We'll need to disable the file operation based CodeActions in LiveShare guest/Codespaces scenarios until they make them work. That's because the underlying system will pre-create the file based off the existence of the light bulb. Meaning when a user is typing <abcd> it's super likely LiveShare will create multiple files: a.razor, ab.razor, abc.razor, 'abcd.razor' etc. and destroy users file systems.

This alone may be a difficult problem to handle. Some ideas would be to implement a MiddleLayer (assuming the LSP platform supports them for CodeActions) or somehow utilize the InitializationOptions OR just pass in an extra parameter/service to the Razor language server that's VS aware.

[ryanbrandenburg]

Looks good, just curious about a couple things.

[ryanbrandenburg]

Could you make this Lazy<ILanguageServer> to future proof it against O# upgrade? In new version of O# there's a possibility of a DI infinite-loop (O# is working on a fix last I heard).

[TanayParikh]

Hmm, so I just tried that System.Lazy<ILanguageServer>, but it results in the endpoint never being constructed in the first place.

It seems in the current version of O#, ILanguageServer is already available, so perhaps the Lazy<ILanguageServer> isn't recognized?

[ryanbrandenburg]

How did you determine where it was appropriate to put cancellation checks? Obviously once at the top is likely to be insufficient, but maybe before every async call is too often? I have little experience with this, so mostly for my own education.

[TanayParikh]

My reasoning was certain functionality like code actions, hover & completions are likely to be triggered very frequently (just by moving a mouse / typing a character), and subsequently dismissed / cancelled frequently (when the mouse is moved further along the path / next character is typed).

For this type of functionality, I think we should be a bit more aggressive in our cancellation checks, which is what I've tried doing here.

[TanayParikh]

Ahhh one other note I forgot to mention that can totally be done in a follow up.

Created: https://github.com/dotnet/aspnetcore/issues/25128 & pulled into current sprint.

Meaning when a user is typing <abcd> it's super likely LiveShare will create multiple files: a.razor, ab.razor, abc.razor, 'abcd.razor' etc. and destroy users file systems.

😱 that doesn't sound too good.