Blazor - Order that form elements are changed affects value returned from overwritten component parameter

[mrlife]

Describe the bug

I have a <select> element in a component called MySelect. In an EditForm I have MySelect and an InputTextArea.

MySelect has a Parameter called SelectedValue that receives the selected value, if there is one. An @onchange on the <select> assigns the new value to the SelectedValue Parameter.

The MySelect in the form has an @ref on it called MySelectComponent. When the form is submitted, I get the value of MySelectComponent.SelectedValue.

The issue is that the order that the form elements are changed makes a difference. If the InputTextArea is changed after the <select> in MySelect is changed, MySelectComponent.SelectedValue returns the value it was given, not its updated value. If the InputTextArea is not changed or is changed before the <select> in <MySelect> is changed, the expected new value is returned by MySelectComponent.SelectedValue.

No RenderFragments are being used. Reference to what's documented: dotnet/AspNetCore.Docs#18144 (comment)

Particularly:

The password example in the docs section about data-binding does write to its parameter, which is exactly what you shouldn't do?

It doesn't use a RenderFragment for content, so it's not a problem.

Further technical details

• ASP.NET Core version: 3.1.7
• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version: VS Mac 8.8 Preview (8.8 build 1532)
• Include the output of dotnet --info:

.NET Core SDK (reflecting any global.json):
Version: 3.1.401
Commit: 39d17847db

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.15
OS Platform: Darwin
RID: osx.10.15-x64
Base Path: /usr/local/share/dotnet/sdk/3.1.401/

Host (useful for support):
Version: 3.1.7
Commit: fcfdef8d6b

.NET Core SDKs installed:
3.1.100 [/usr/local/share/dotnet/sdk]
3.1.101 [/usr/local/share/dotnet/sdk]
3.1.102 [/usr/local/share/dotnet/sdk]
3.1.200 [/usr/local/share/dotnet/sdk]
3.1.201 [/usr/local/share/dotnet/sdk]
3.1.202 [/usr/local/share/dotnet/sdk]
3.1.300 [/usr/local/share/dotnet/sdk]
3.1.301 [/usr/local/share/dotnet/sdk]
3.1.302 [/usr/local/share/dotnet/sdk]
3.1.401 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.16 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.17 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.19 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.20 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.21 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

[SteveSandersonMS]

This is as expected, and is the reason why we say components shouldn't try to overwrite their own parameters. If you do this then your overwrites will themselves be overwritten if the parent component re-renders.

The correct way to implement what you have here is for your MySelect to expose a bindable parameter: https://docs.microsoft.com/en-us/aspnet/core/blazor/components/data-binding?view=aspnetcore-3.1#parent-to-child-binding-with-component-parameters

Thanks for pointing out the misleading documentation. I've filed dotnet/AspNetCore.Docs#19789 to correct this. BTW even though the existing doc is misleading, its approach to chained bind will actually work.

[mrlife]

Hi @SteveSandersonMS, thanks for taking a look. I will be sure not to write to any Parameters.

The are 2 other potential changes needed in the docs.

The Parent to Child section on that docs page appears to use the same technique of overwriting the Parameter.

• Should this be changed as well?

    [Parameter]
    public int Year { get; set; }

    [Parameter]
    public EventCallback<int> YearChanged { get; set; }

    private Task UpdateYear()
    {
        Year = r.Next(10050, 12021);

        return YearChanged.InvokeAsync(Year);
    }

In the Chained Bind section, it says

A chained bind can't be implemented with @bind syntax in the child component. The event handler and value must be specified separately.

Then it goes on to use the same technique from Parent to Child

<PasswordField @bind-Password="password" />

cc @guardrex

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

[guardrex]

@mrlife ... I'm working on the examples and text this morning on Steve's doc issue. It's tricky, and I'll likely need help based on the observed behaviors. I think I'll be able to lay out the scenarios that we're looking at thus far. The rubber 🦆 is helping me sort through through them for an upcoming issue comment.

I do want to point out in passing here that these chained bind examples don't (apparently) suffer from parent rerendering problem where the child would have it's password value changed ... that's what I thought this whole 'don't write to params' guidance was all about. It's true tho that if a field isn't used in the child the child will have it's password value changed if the parent changes its password value. To avoid that, yes ... the child can use a field. However, the child always has to write to the parameter to get the chained bind to work (thus far ... let's pick up on that point over there after I finish my remarks). Ryan's own example that got the ball rolling with the example does write to the parameter to make the binding work, and AFAICT it won't work without it ...

dotnet/AspNetCore.Docs#14144 (comment)

Let me finish up my remarks over on the other issue, and let's continue the discussion over there. This isn't an engineering problem ... it's a docs problem. Let's sort it out as a docs issue. I'll ping everyone over there shortly for further discussion after I finish up my comments and illustrate my own mental challenges and misunderstandings 🙈 (Steve will no doubt chastise me now for partying too much in college and frying too many brain cells! 😄). I'll get back to everyone shortly ... stand-by. 🚀