[Blazor] @if directive

[mrpmorris]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I'd like to be able to create markup that is nice to look at and easy for a non-programming colleague to improve the visual design of.

@if (IWantToWriteNiceCode)
{
  <ThisDoesntFloatMyBoat/>
}

This isn't nice to look at, it's quite verbose, and my non-programming colleague would undoubtedly break the logic when changing the contents to make them look good.

Describe the solution you'd like

I'd like to be able to have if and foreach directives, so my colleague only needs to know not to change any html attributes that start with an @ symbol (as is already the case).

<ThisDoesFloatMyBoat @if=IWantToWriteNiceCode/>

The preceding code is much nicer to look at, quicker to type, uses only a single line so uses less space, and easy to see what can be moved/altered without breaking things.

I would also like to be able to replace the following

@foreach(var person in People)
{
  <li>@person.Name</li>
}

With something more simple such as

 <li @foreach-person="People">@person.Name</li>

I resist giving judgement on a switch statement :)

Additional context

https://i.ibb.co/8gsnjg7/Fm68-Ngz-Xw-AA8xqv.png

[SteveSandersonMS]

The @if directive attribute looks good to me. It has clear meaning and doesn't introduce any new difficulty.

I would recommend not getting bogged down in the @foreach attribute though. That's far weirder, declaring the name of a variable as a suffix of an attribute name. Something else like @foreach="person in People" is more obvious but it's still a bit of a mess conceptually because you might also want to refer to person in some other attribute on the element, breaking the syntactical hierarchy.

I think @if is something we could pursue as an attribute in the short term, but am not sold on other flow constructions (while, for, foreach, switch, try/catch, using, etc) having new special-case alternate syntax on top of their existing C#-style syntax.

[mrpmorris]

I think if and foreach are likely to be the two most commonly used constructions in .razor files. @if would be a very welcome addition, and I think a @foreach would be equally as useful.

I agree on not putting in all the other control flow.

I thought the foreach was quite intuitive as it follows the @bind directive pattern

@directive-Identifier=Source

• @bind-Value=Source
• @foreach-currentItem=Items

And it matches the order of foreach item in Source to make it easy to remember.

[snowfrogdev]

I think this has merit. When I compare Razor template control flow with how Angular and React do it it feels like Razor is a hybrid that inherits the cons of both but not so much the pros.

Angular uses attributes, which has the benefit of keeping your html looking like html. The con is that it is essentially some kind of DSL and encourages mixing logic with your presentation.

React uses actual JavaScript control-flow statements, as you usually write html snippets inside your JavaScript files, which has the benefit of using actual programing language constructs, in an actual programing language file, to handle logic. The con is that you end up with presentation mixed in with your logic.

Razor has you wrap your HTML, inside C# code, inside HTML, in an HTML file. It feels a little awkward, to me and you basically end up with all of the cons of React and Angular... a DSL with logic mixed in presentation mixed in logic.

At the end of the day it's probably mostly a question of preference and what you're used to. For what it's worth, my preference is for something closer to Angular. Which is kind of what this issue seems to advocate for.

[mrpmorris]

At the end of the day it's probably mostly a question of preference and what you're used to. For what it's worth, my preference is for something closer to Angular. Which is kind of what this issue seems to advocate for.

@snowfrog
I must confess to being a little influenced by Angular :) I used to use it a number of years ago and thought it was a real improvement over vanilla ASP markup that I used to write a very long time ago.

Razor syntax is certainly an improvement over vanilla ASP, but still quite similar. I think the @if @foreach approach looks more declarative rather than imperative.

Of course, we'd need <text> to support these too, otherwise we'd be forced to implement an HTML element into the result that we otherwise wouldn't want.

[javiercn]

@mrpmorris I understand the appeal of the solution you are proposing.

However, I do not agree with the reasoning to add something like this to Razor. You might prefer a more declarative style over a more imperative style, but that is to a large degree a matter of taste/preference.

Adding these types of constructs/primitives goes against the core philosophy or Razor, which is expressing the logic for rendering the UI directly in C#, without having to learn a new DSL. We already had this model with aspx and we moved to something like Razor for a reason.

I do not see the value of adding yet another way of doing the same thing to the language. I understand that it might appeal to some design preference or aesthetic sense, but I do not believe that there is a meaningful advantage over using the language vs having an alternative way based on a DSL.

On the contrary the drawback is that it adds two different ways of doing the same thing at a very low level.

This is something that I would say we are not likely to change, and if we do, I will think we would end up with a different language that is just not Razor anymore.

I agree with @SteveSandersonMS that we might potentially add something to conditionally render a block, but I would go as far as to say that it would not be called @if.

[mrpmorris]

@javiercn
There is one very good point that you've missed.

If I give a project with .razor files to a non-programmer colleague whose job it is to make my functional UI actually look nice to users, they'll break it. I've seen it happen a number of times already, and in each case I had to spend time teaching the colleague razor programming in order to understand how to change things without breaking them.

On the other hand, when I gave them Angular apps to change I didn't have any problems at all.

Many companies have separate job positions for "full stack" programmers and UI designers. Not all UI designers know how to write code, or even want to learn.

The @if @foreach pattern follows the existing HTML paradigm, which they will already know very well.

I think limiting the discussion to what programmers want is excluding the needs of too many others.

[StevenTCramer]

@javiercn

And yet we go to all the trouble to make minimal APIs to help people to get started. faster. Removing Main etc...
Now we have two different ways of doing the same thing. Controllers and Minimal API.
Why did we change those? Because we thought it was for the better.

I will think we would end up with a different language that is just not Razor anymore.

Maybe people want Razor to change?

My thoughts are people would vastly prefer @if over the current format. And the ones I have asked do.

And if you didn't call it @if what would you suggest?

[davidfowl]

However, I do not agree with the reasoning to add something like this to Razor. You might prefer a more declarative style over a more imperative style, but that is to a large degree a matter of taste/preference.

I think this statement by @javiercn is key. This is largely about style/taste/preference and really the spirit in which razor was created. It's "smooth" integration of C# with HTML, not a DSL with C# expression constructs interleaved with HTML. This is about form, not function.

[StevenTCramer]

@davidfowl yes it is 100% about form. But why did you make Top level statements? The Main class functioned just fine.

As a rule we try and keep code out of Razor as much as possible. We have a @code section and "code behind" to do this. I think this "form" follows along the concept of top-level statements and minimal APIs. More concise easier to work with code.

[davidfowl]

Why did we change those? Because we thought it was for the better.

I think the "we" is relevant here. The framework/language designers had to agree it was a net positive. These debates are normal, and when the designers aren't fans of the "style/form" then the changes don't happen.

[mrpmorris]

@davidfowl See my comment regarding not everyone is a developer - #9243

[davidfowl]

I read the comment, but my point still stands. I'm not saying I'm for one way or the other with this specific issue, but sometimes, what looks like small feature is really a paradigm shift (like this issue) and a much bigger change to the overall approach. This is the reason why this issue is being met with resistance. It doesn't fit the existing mold, it's different and as a result, the engineering team needs to spend more time understanding it and the tradeoffs etc.

That's not to say we don't change our minds, but it won't be a quick fix. Currently, we are not convinced that changing the style of razor for designers is worth introducing a new paradigm.

[StevenTCramer]

Debates are normal and healthy. That is how we improve.

[mrpmorris]

@davidfowl It's more of an additional paradigm rather than a paradigm shift (which implies people must change what they already have). But it's certainly one that would make it a lot easier for non-programming visual designers to work with, so I can get on with coding Blazor instead of having to manually fit someone else's design changes into my app, or (even worse) teach programming to someone who hates it.