Layouts?

[pm64]

Feature description

Would it be possible to support Blazor layouts, such that @Bind() could be used in a file like MainLayout.razor?

Code sample

No response

[klemmchr]

This should be supported already using a custom MVVM component with source generators as described in the Readme. Could you give this a try and see whether this works for you?

[pm64]

Thanks @klemmchr. This actually does not appear to work for Blazor layouts because the generator generates a protected parameterless constructor. When the component is rendered, System.Activator.CreateInstance() throws MissingMethodException: No parameterless constructor defined for type 'MyType'.

[klemmchr]

This actually does not appear to work for Blazor layouts because the generator generates a protected parameterless constructor. When the component is rendered, System.Activator.CreateInstance() throws MissingMethodException: No parameterless constructor defined for type 'MyType'.

The generator generates a partial class that is just added on top of your user code. If you need a public parameterless constructor, you can add it by yourself.

[MvvmComponent]
public abstract partial class MyLayoutComponentBase : LayoutComponentBase
{
    public MyLayoutComponentBase()
    {
    }
}

[pm64]

I can't do that because you can't have 2 members (in this case constructors) with the same name and parameter types -- so it results in: Type 'MyLayoutComponentBase' already defines a member called 'MyLayoutComponentBase' with the same parameter types.

[klemmchr]

Good point, that's annoying. Best would be to entirely remove the constructor from the code generator but this is a breaking change. But I honestly don't think that a lot of people would be affected since this is such a niece feature.

[pm64]

Yikes. I guess I'll just handle PropertyChanged manually in the layout. I hope you'll consider some kind of solution to this though, maybe the code generator can suppress the constructor if a non-generated parameterless constructor is detected?

[klemmchr]

Detecting that should be possible but it probably is a mess. Probably easier to get rid of the constructor in the first place. It's not needed anyways. I could do a release for that tomorrow.

I just thought about a hack for your problem. I did not think about it for too long, but you could "solve" your issue by introducing a wrapper class for the generated component with a public constructor. Not pretty but gets the job done for the moment.

[pm64]

I tried that too, but the "same name/parameters" restriction applies to derived types :\

[klemmchr]

This is confusing since this code compiles fine:

public abstract class Test
{
    protected Test()
    {
        
    }
}

public abstract class DerivedTest : Test
{
    public DerivedTest()
    {
        
    }
}

https://dotnetfiddle.net/YAK5mk

[pm64]

My apologies, operator error, your workaround does work.

[klemmchr]

Given that this workaround is suitable for the moment I would close this issue and do the necessary changes with the next major release.