.NET 8 Blazor - Form With Multiple Buttons Inconsistent Behavior

[sbwalker]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Blazor exhibits inconsistent behavior when handling forms with multiple buttons. The following is an example form which contains 2 buttons. When a user clicks on a button the component should tell the user which button was clicked:

<form method="post" @onsubmit="Submit" @formname="MyUniqueFormName">
    <AntiforgeryToken />
    <button type="submit" class="btn btn-primary" name="Action" value="Action1">Action1</button>
    <button type="submit" class="btn btn-primary" name="Action" value="Action2">Action2</button>
</form>

@if (!string.IsNullOrEmpty(_message))
{
    @((MarkupString)_message)
    
}

@code {
    [SupplyParameterFromForm] public string Action { get; set; }

    private string _message;

    private void Submit()
    {
        _message = $"<br /><p>";
        _message += "Action: " + ((Action != null) ? Action : "NULL");
        _message += "</p>";
    }
}

Running this code using Static rendering works correctly - it displays an action of “Action1” or “Action2” depending on which button is clicked:

However, running this code with Interactive rendering, the action always returns NULL.

Expected Behavior

Regardless of the render mode being used, form handling should be consistent. In this example it should return the action related to the button clicked.

Steps To Reproduce

Sample component code is included in the issue report. The component would need to be instantiated using Interactive render mode to reproduce the problem reported.

Exceptions (if any)

No response

.NET Version

8.0.1

Anything else?

No response

[javiercn]

@sbwalker thanks for filing the issue

There is no silver bullet, if you want to create a component that works across render modes, HTML semantics go so far. Using a plain form and our binding system has its limitations, and when you reach those, the best approach is to wrap the form in a reusable form component in a way that you can support the different environments.

An HTML form handled via SSR has very different semantics to a form handled via Interactive rendering (In one is the HTML spec defining a concrete set of semantics in the other is your app handling an event and deciding what to do.

It's not our goal that all interactive form handling scenarios are isomorphic with SSR scenarios and vice versa, and while we take care of common scenarios, more complex scenarios require the developer to account for the different environments the form will have to work.

The other thing that I would add is that, even if Blazor provides static server rendering and form handling, there's no need to make all features in an application work in all environments. It is ok to have complex forms that require interactivity to work (there it pays off) and use SSR for simple forms.

In this case, one way this can be accomplished is by using a custom event to identify the action value from the button in interactive scenarios.

You setup a custom OqtaneSubmitEvent on the form that looks at the submitter​ and passes that value to the server in interactive scenarios and sets the Action parameter, and then you raise an event from your component. For example:

<OqtaneActionForm OnSubmit="Handler">
  <OqtaneAction Value="Action1" />
</OqtaneAction>

@code
{
  public Task Handler(OqtaneActionSubmit submit)
  {
      if(submit.Action == "Action1")
      {
      }
  }
}

[sbwalker]

The other thing that I would add is that, even if Blazor provides static server rendering and form handling, there's no need to make all features in an application work in all environments. It is ok to have complex forms that require interactivity to work (there it pays off) and use SSR for simple forms.

I totally agree... and this is the general approach I am taking when migrating traditional Blazor apps to .NET 8. However, I do not consider a form with 2 buttons to be a "complex form". Forcing this to be an interactive component seems excessive and not in alignment with the new "light-weight" Blazor component approach in .NET 8.

I will explore your suggestion above further to determine if the code complexity/maintainability is worth the effort... or if it is better to accept the performance penalty of using an interactive component for this scenario.