razor
razor copied to clipboard
dotnet
Enable HTML light bulbs in Razor scenarios
I'm not entirely sure if we'll need to allow list these light bulbs given the coordinate plane for HTML is identical to the top-level file (although different content). We'll want to play with the light bulbs available and see what happens.
@jimmylewis would you mind providing a list of light bulbs we could cross-check?
We currently have 3 lightbulbs for HTML:
- for an
<img>tag, encode the src as base64 - for an
<img>tag, add height and width attributes based on the src - for any tag, remove the tag and leave its contents behind
1 and 2 were existing features in the old HTML editor. 3 was a feature from the Html Tools extension. At some point we'll add more (e.g. Html Tools has more we haven't ported yet, we may add some for CSS that would apply in <style>, etc).
@jimmylewis are these rolled out in the html editor? I'm implementing this, and its all cool, but I'm wondering if you got any pushback on number 3, since it shows up everywhere. Its quite the departure from the current state of only seeing light bulbs where there is something "interesting" to do in C# (particularly with our already filtered list of C# actions)
They're rolled out in the HTML editor, but so far the HTML LSP editor is only rolled out internally (opt-in otherwise). LSP is forced on for Razor and I think now by the Angular Language Service extension (affects *.component.html). We're launching flights starting in 17.5 Preview 1 for all HTML files.
That light bulb action in particular was taken from the HTML Tools extension that Mads wrote. It only lights up when the caret is inside an opening element tag, so not quite everywhere but might feel like it. If we get negative feedback, I could see it being reasonably scaled back to just within the element name or turned off entirely.
I think what surprised me most was that it is offered for elements without content too. I can see the usefulness of it, but not sure how Razor devs will respond.
Makes me wish we had an options page :)
How would you feel about making the "Remove tag" code action be a resolvable one? Seems like potentially a huge amount of json being passed around in order to show the code action list (eg. if the cursor is on the root <html> element, the code action contains almost the entire document. We also need to process the edits you send back, on our side, so would be nice to avoid that work unless the action is being applied.
Also, we currently have an allow list of C# code actions that we expose to the user, and I'm wondering if we should do the same for Html. With only 3 at the moment, it seems unnecessary, and I'm not sure I can think of an example of a HTML action we wouldn't want, but not sure. If so, we'd need some way to identify the code actions. Roslyn just has a "CustomTags" bit of data they put in the Data field of the code action. For resolable code actions you basically already have this with ResolverName on the HtmlCodeActionData so if everything becomes resolvable then we're probably all good there.