Create `@static` directive that results in a static class being generated

[bonsall]

I would like to create small static extension methods that allow me to utilize razor markup syntax. This was best summarized by Damian in a different thread, so I will quote him here.

Is it fair to summarize this as supporting a new kind of .razor file template that produces a static class rather than a component type, and within it only a @code block containing static methods (using Razor syntax or otherwise) would be allowed? Perhaps by a new @static directive that is mutually exclusive with other directives that assume a non-static type (e.g. @inherits, @inject, etc.):

@static
@code {
    extension(ComponentFactoryCollection componentFactories)
    {
        public void AddMyOtherComponentStub()
        {
            @<div class="my-stubbed-component">
                @parameters.Get(x => x.ChildContent)
            </div>)
        }
    }
}

My personal preference would be to omit the @code { } ceremony and just assume your creating static methods, but I'll let you guys figure out those details.

Original feature request and my motivation are in the ASP.NET Core Roadmap discussion.
dotnet/aspnetcore#64788 (comment)

[davidwengier]

Quick take:

Having no @code, and just C# code in a bare .razor file would be really weird.
Having only @code and no Razor/html in a bare .razor file would really weird.

I think if we were to do this, a static Render method for for anything not in a code block makes sense. You'd still be able to put extension methods etc. in code blocks, and maybe we could special case whitespace-only Html content to not generate the Render method, but rules around it seem odd to me.

[bonsall]

In my opinion generating a Render method from content outside the @code block is not very practical from a usage standpoint. Since the Render method would be static, you wouldn't be able to pass any parameters to it, at least not without some new magical syntax. So then you would just have static content in that Render method. This would most certainly lead to abuse from inexperienced devs who would start adding static properties to the class to make the content in this Render method dynamic.

I think something like this is pretty clean and elegant.

@static

public static RenderFragment RenderSimpleDiv() => __builder =>
{
    <div class="my-simple-div">
        Some simple content
    </div>
}

public static RenderFragment RenderSimpleDivAlternate() =>
    @<div class="my-simple-div">
        Some simple content
    </div>;

public static int AddOne(int number) => number++;

extension(ComponentFactoryCollection componentFactories)
{
    public RenderFragment AddMyOtherComponentStub()
    {
        componentFactories.AddStub<MyOtherComponent>(parameters =>
            @<div class="my-other-component-stub">
                @parameters.Get(x => x.ChildContent)
            </div>);
    }
}

Understandably not having a @code block is a bit weird, but the reduced nesting and minimized reading I need to do in the file make it worth it.

[davidwengier]

That might be clean, but it doesn't look like Razor, and would be an enormous amount more work for the Razor compiler to understand. Things that make the feature harder to implement, make it harder to put the feature in. See also: https://learn.microsoft.com/en-us/archive/blogs/ericgu/minus-100-points

[bonsall]

@davidwengier that is a very good point, and an enlightening read. I can very much understand not wanting to take on more than is necessary.

I would still consider what you have proposed as a big win, as I would get my extension methods with razor syntax. I'm more or less hoping that my concerns and opinions from my last comment are taken into consideration if and when you all start to work on this.

[MattParkerDev]

What you are wishing to achieve is technically possible today, albeit not the most elegant. Create a regular razor file, @code block, then inside that declare your static class. You can then create methods etc that return RenderFragments with razor markup, like your example.

The inefficiency is one extra instance class/component that is technically unused.