Blazor sets EditForm Model to null in unexpected situations

[halter73]

Given the following component:

@page "/null-forms"

<h3>Null Forms</h3>

<p>@message</p>

<EditForm Model="Input" FormName="main-form" OnSubmit="OnMainSubmit">
    @if (!HideOptional)
    {
        <div>
            <label>Optional input: </label>
            <InputText @bind-Value="Input.Optional" />
        </div>
    }
    <button type="submit">Submit primary</button>
</EditForm>

<form @formname="secondary-form" @onsubmit="OnSecondarySubmit" method="post">
    <AntiforgeryToken />
    <button type="submit">Submit secondary</button>
</form>

@code {
    private string? message = null;

    [SupplyParameterFromQuery]
    private bool HideOptional { get; set; }

    // Specifying the FormName works around the bug during secondary-form submission,
    // but not the bug when there's no optional input loaded.
    //[SupplyParameterFromForm(FormName = "main-form")]
    [SupplyParameterFromForm]
    private InputModel Input { get; set; } = new();

    private void OnMainSubmit()
    {
        message = $"OnMainSubmit: {Input.Optional}";
    }

    private void OnSecondarySubmit()
    {
        message = "OnSecondarySubmit";
    }

    private sealed class InputModel
    {
        public string Optional { get; set; } = "";
    }
}

You will see an error like the following:

InvalidOperationException: EditForm requires either a Model parameter, or an EditContext parameter, please provide one of these.
Microsoft.AspNetCore.Components.Forms.EditForm.OnParametersSet()

This happens if you either click "Submit secondary" or click "Submit primary" with ?hideoptional=true. You can work around the "Submit secondary" issue by specifying [SupplyParameterFromForm(FormName = "main-form")] for the InputModel, but I'm not sure about a workaround for "Submit primary" with ?hideoptional=true other than putting Intput ??= new() in OnInitialized().

This came up when working on the Identity Razor components for the .NET 8 project templates. DeletePersonalData.razor and Email.razor

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[marinasundstrom]

This was annoying. I have had quite a lot of problems with the changing behavior of forms throughout the previews and RCs. This was the last one that I tackled.

[oliverw]

This is extremely annoying and still happening with .NET 8 RTM.

I was able to reproduce the problem reliably using a checkbox binding:

public class BillingModeForm
{
    public bool Annual { get; set; }
    public string NoOp { get; set; }
}

<EditForm FormName="billing-mode" Enhance Model="@BillingMode">
    <div class="form-check form-switch">
        <InputCheckbox class="form-check-input" role="switch" bind-Value="BillingMode.Annual"></InputCheckbox>
    </div>

    <InputText @bind-Value="BillingMode.NoOp" class="d-none"></InputText>
    <button class="btn btn-primary" type="submit">Submit</button>
</EditForm>

Without the NoOp property, the form would always be null on Post after unchecking the checkbox (switch).

[oliverw]

This issue should really be part of the 8.0.x milestone. It is extremely annoying to have dummy field in many of your forms just as a work around for this.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

Discussed this offline. We may end up creating an analyzer to warn customers from falling into this pitfall.