search

dotnet / razor

Compiler and tooling experience for Razor ASP.NET Core apps in Visual Studio, Visual Studio for Mac, and VS Code.
https://asp.net
MIT License
492 stars 190 forks source link

IntelliSense bug for Razor Components #4511

Open mikadumont opened 3 years ago

mikadumont commented 3 years ago

Copying customer ask here:

My main usage is upgrading a 3-year-old web application (currently running a Vue.js frontend + .NET Core 3.1 backend) to a Blazor WASM hosted on aspnet with .NET 6. I’m currently using VS 2022 preview 3.1 most of the time.

It’s hard to decide which issue is my dotnet/aspnetcore#1 but if I had to choose only one improvement, I’d say that proper intellisense within the blazor components tags would be the one. There’s nothing like images to describe this so, here we go.

This is good intellisense (a bit sluggish to appear but expected from a preview build) razor-issue1

Here I get the values for that enum. Perfect!

But then this is just not helpful… to the contrary, it’s even a nuisance. razor-issue2

It takes about 30 seconds to scroll the whole list and why do I get angular stuff in there?

Sure feels like every possible keyword has been dumped in the list.

And here again, intellisense is not really helping (would be nice to prioritize the list of options supported by the component) razor-issue3

NTaylorMullen commented 3 years ago

@mikadumont would you mind suggesting to this person in their first issue about having too many completion items provided to use the filter? I'd be curious if that would resolve their concerns / be appropriate.

NTaylorMullen commented 3 years ago

@ToddGrun / @jimmylewis is there an issue about Angular & friends not having their own item filters? Also, if the app doesn't have angular referenced are we able to just not provide the angular completions?

jimmylewis commented 3 years ago

@NTaylorMullen the ng- completion comes from our HTML editor, not the Angular tooling. We don't have smarts to determine if you're using Angular in the project, but that's also why we collapse it down to only one completion item (if you choose that, we refresh completion with loads of ng-specific stuff). Our assumptions are that in any generic HTML attribute completion scenario: a) one item in completion is easy enough to ignore, b) if you are using Angular, this is super useful to have. If it were the only extraneous one, I don't think we'd get much complaint (we haven't had any feedback on it to date), but when all of the attribute completions are extraneous, it's a much more severe problem.

Can Razor smartly determine when to delegate to HTML in these cases?

jimmylewis commented 3 years ago

Another thought I had: would it be a better experience to tweak the sort order so that the Blazor completion items are listed first? E.g. taking from the element completion screenshot

DynamicComponent
EditForm
ErrorBoundary
FocusOnNavigate
a
addr
area
b
...
NTaylorMullen commented 3 years ago

Can Razor smartly determine when to delegate to HTML in these cases?

When we adopt the LSP embedded language re-design I have proposed we'd be able to do it easily; doing anything prior to that would be more or less a hack 😢.

Another thought I had: would it be a better experience to tweak the sort order so that the Blazor completion items are listed first? E.g. taking from the element completion screenshot

Ya that's definitely a possibility. Hmmm probably a pretty good idea. I worry about making that drastic of a change in p5 though hmmm. Will have to think about it more