Aspnetcore: Provide improved Blazor/Razor syntax

[DumboJetEngine]

Just a suggestion/idea:

Please provide alternative syntaxes for blocks of C# code, placed inside HTML like this:

@for (int i = 1; i <= 30; i++)
{
      <option>@i</option>
}

Visual Studio does a bad job at auto-formatting mixed code (C# and HTML), especially after you install add-ons that add additional formatting.

I believe it is easy and much more elegant to use something similar to angular's attributes, e.g., using a @-sth(...) format:

<option @-for(int i = 1; i <= 30; i++)>@i</option>
<option @-foreach(var name in names)>@name</option>
<option @-if(!string.IsEmptyOrWhitespace(name))>@name</option>
<option @-else()>@name</option>

<div @-switch(id)>
    <span @-case(1)>One</span>
    <span @-case(2)>Two</span>
</div>

This will keep things readable and simple, both for developers and auto-formatters.
Transforming these attributes to normal Razor syntax when you compile them should be straightforward.
Also, allowing developers extend these attributes should be also doable, and that would be even cooler.

I am excited with Blazor, but hearing about brackets inside HTML takes half of my excitement already.

And probably I am not the only one feeling this way.

[mkArtakMSFT]

Thanks for contacting us, @DumboJetEngine.
This is not something we plan to do.

[DumboJetEngine]

@mkArtakMSFT
Oh!
So, many down-votes and no explanation for them!
Was it such a bad idea, really?!?!
OK.
I have no idea who are the people that down-voted this (if they are experts, part of the aspnet team, 100% C#-dedicated people or just passers-by), but I really had the impression that many people dealing with this on an every-day basis would like to see this part of the framework and tooling change.
A bad estimation on my part maybe. ;)
Apologies for the backlog noise.

[mkArtakMSFT]

@DumboJetEngine, we don't want to come along as harsh at all. It's just our triage process is quite time constrained, and we sometimes leave comments and move on, not being too much verbose.
The reason we don't want to make this change is that this is completely different from where Razor is at the moment and that would mean introducing a breaking change. There are existing patterns for doing this which the Razor community likes and is used to. We can't break all those scenarios. Neither we can justify spending time on introducing a parallel model of doing essentially something which is possible to do in a different way.

Hope this helps.

[Andrzej-W]

@DumboJetEngine You have to take into account that it is very popular project with plenty of messages every day. It is simply impossible to write long answers to every suggestion, especially if something has already been discussed earlier. For your reference here is a similar issue: https://github.com/aspnet/Blazor/issues/960 with 14 down-votes.

[DumboJetEngine]

Thank you all. :)
I didn't expect any extensive reply initially, but the account of down-votes socked me a bit and made me wonder.