Bind directive attribute event parameter HTML event completions

[Peter-Juhasz]

Summary of the changes

Created a basic completion provider for completing HTML event names for @bind:event directive attribute parameter, primarily to cover the most common use case: setting it to oninput or onchange.

What is not included:

• Semantics of the HTML element the binding is applied on (see below at Alternatives)
• Event symbols of Component, it lists the HTML events only
• The "applicable to span" is not set, if I'm not mistaken it is not supported to set by the completion provider yet

Alternatives for schema data:

• Simple list of common form control events to cover the 99% use case (implemented in this PR)
• Include a schema for the list of all events as data (like VS Code HTML LS does)
  • But this seems like a broader initiative to have this in place as a fundamental service to be queried by other services
  • It also needs a process to be kept up to date
  • The schema found in the HTML LS repository doesn't contain any semantics, it is flat list among all attributes
• Dispatch call to the HTML LS in a virtual document to a virtual position to list the attributes of the element in context and then filter those to keep "events" only.
  • But how to distinguish event symbols, if the HTML LS does not seem to either
  • Use a name based "starts with on..." hack, which is not reliable
  • Altogether very complicated for small value but also incomplete and/or unreliable

[DustinCampbell]

Thank you very much for your contribution @Peter-Juhasz!

[DustinCampbell]

@Peter-Juhasz: Please rebase this to main. release/dev17.14 is taking fewer changes as that release locks down.

[Peter-Juhasz]

@Peter-Juhasz: Please rebase this to main. release/dev17.14 is taking fewer changes as that release locks down.

This is quite challenging because I'm running into conflict where I have absolutely no idea what I should choose. :D

And my VS is crashing between each change. :D Probably because I don't have the bits in my public preview that you have in main already. We discussed this with @davidwengier that after I move on from the VS preview release commit, I bump into breaking changes and can't test my changes locally anymore.

@DustinCampbell What is your recommendation on the right process overall here and how shall we proceed?

[ryzngard]

@Peter-Juhasz: Please rebase this to main. release/dev17.14 is taking fewer changes as that release locks down.

This is quite challenging because I'm running into conflict where I have absolutely no idea what I should choose. :D

And my VS is crashing between each change. :D Probably because I don't have the bits in my public preview that you have in main already. We discussed this with @davidwengier that after I move on from the VS preview release commit, I bump into breaking changes and can't test my changes locally anymore.

@DustinCampbell What is your recommendation on the right process overall here and how shall we proceed?

Currently you basically have a few options:

1. Install dotnet/roslyn into the same hive. You can do this from build.cmd -deployExtensions after running restore.cmd in the repo.
2. Keep this targeted here and once everything is approved we can handle the work to retarget accordingly
3. Rely on expansive unit testing :) You should be able to run those in any VS that builds the repo.

I wouldn't recommend trying to figure out the rebase yourself. It will get tedious fast

[davidwengier]

Can we avoid this tree walk? The owner here could be an arbitrarily nested node, and this call can happen on every keystroke.

I suspect there is a relatively small set of nodes that the owner could be, with a well defined number of ".Parent.Parent" calls needed to get to where we want to be.

[davidwengier]

To be clear, I mean doing something like:

if (context.Owner is MarkupTextLiteralSyntaxNode { Parent.Parent: MarkupTagHelperDirectiveAttributeSyntaxNode owner })

(Typing on my phone, and only guessing at type names)

[Peter-Juhasz]

Good catch! I just sent a fix already.

[Peter-Juhasz]

🌴 FYI: I will be traveling in the rest of this week, and while I can read/reply comments, I won't be close to my desktop workstation to be able to make any meaningful changes. Will be back on Monday next week.

Feel free to make any changes if needed to proceed with this PR until then.

2. Keep this targeted here and once everything is approved we can handle the work to retarget accordingly

I would appreciate if you could help me with that. And when I get back I will reach out to you to discuss how can this work with the least friction on both ends.

[davidwengier]

I suggested option 2 for the other PR, and am happy to do the work to merge and resolve conflicts on both, when the time comes. You've found yourself in an odd timing for VS releases, and I don't see why you should have to pay the price when it's out of your control.

Though technically its out of our control too 😁

[davidwengier]

LGTM

In an ideal world we'd get these from a Html LSP but in reality they're never going to understand @bind:event and seems like even if they did, they wouldn't produce any better list anyway.

[davidwengier]

Actually, I guess I might ask for at least one test in https://github.com/dotnet/razor/blob/main/src/Razor/test/Microsoft.VisualStudio.LanguageServices.Razor.Test/Cohost/CohostDocumentCompletionEndpointTest.cs, just to be sure its all good. Shouldn't require anything except the literal test method, but will at least validate the MEF composition is correct.