Allows you to write methods that contain mixed HTML and C# in Razor Views (.cshtml) / Razor Components (.razor) files.
This is a primitive for composing Razor code that is very low overhead / low concept. Your code calls your code.
In Views (not components): Can be async, can use tag helpers. In Components (not views): Usage and semantics still need figuring out, but we want to build something like this.
<h1>Here is some info about people on the team</h1>
@foreach(var person in people)
{
DisplayPerson(person);
}
@functions {
void DisplayPerson(Person person)
{
@<div>
<h3>
@person.Name is @person.Age
</h3>
@if (DateTime.Now.DayOfYear == person.Birthday.DayOfYear)
{
<h4>Happy Birthday! @person.Name</h4>
}
</div>
}
Person[] people = new Person[]
{
new Person()
{
Name = "Ryan",
Age = 33,
Birthday = new DateTime(1985, 9, 9),
},
new Person()
{
Name = "Dan", // Not Dan Roth, some other guy.
Age = 53,
Birthday = new DateTime(1965, 2, 3),
},
};
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
public DateTime BirthDay { get; set; }
}
}
Is this W A V Y ? SPICY? Have you had cases where you wanted this? What would you add/change/remove?
Just to underline what's new here, it's that with this new syntax, you could include Razor in
@functions
methods, whereas before if you tried, it would syntax error because it's meant to be pure C#?I like the idea and it could help replace helpers, but this also muddies up the rules for what's HTML and what's C#. Most of the time,
@
switches from HTML into C#, and not from C# into HTML. Writing HTML from inside C# is not a clean fit, especially without co-opting any return type or parameter the way@helper
does. Not being able to capture the output inIHtmlContent
is also problematic since most of the rest of the Razor public interface is based on top of it, although I understand that the idea is to be low-level and high-efficiency and it would be very "allocatey".In the end, I can't help but like the way
@helper
solved this problem, by acknowledging that there's going to have to be some magic behind the scenes and so you can't set a return type, and using something like it would also give permission for the method signature to be malleable and different from exactly what's entered - ie in a low-level scenario, there could be an alternate method generated which output text to a writer passed in as an extra parameter instead of constructing anIHtmlContent
to return. If every helper up and down the stack got that for free, I imagine there could be some savings.Regarding the syntax: I remember that there's a feature like
@<something></something>
in classic Razor too, which comes with a magicalitem
parameter which you couldn't change the name of. I don't remember the name of the feature and I have no idea if it made it to Core or not, and I think the syntax has a lot to do with that. Considering every other Razor syntax rule, it looks too close to a typo to feel natural, and it's basically impossible to Google.