Data binding example shows component overwriting its own parameter value

[SteveSandersonMS]

We tell people not to create components that overwrite their own parameters, but unfortunately one of the examples in the docs does exactly that: https://docs.microsoft.com/en-us/aspnet/core/blazor/components/data-binding?view=aspnetcore-3.1#child-to-parent-binding-with-chained-bind

This has led to some confusion, e.g., dotnet/aspnetcore#25377

Could we please update the docs not to do that? In the case of the password example, I think the child component could simply omit the line that does Password = e.Value.ToString(); and it should still work fine.

Also the info at https://docs.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-3.1#overwritten-parameters-with-renderfragmentis a little misleading. It says that:

Parameters are overwritten under the following conditions:

• A child component's content is rendered with a RenderFragment.
• StateHasChanged is called in the parent component.

I would instead say something like New parameter values are supplied, typically overwriting existing ones, when the parent component re-renders. There's no reason to talk about renderfragments or StateHasChanged here, as far as I know. The parent component doesn't even necessarily have a StateHasChanged method, as that's specific to ComponentBase which not all components necessarily derive from.

[guardrex]

omit the line that does Password = e.Value.ToString(); and it should still work fine.

Will do. It changed in a bad way (that line anyway) since Ryan first handed it over. EDIT: It was the original approach provided for the doc. This is his original version ...

#14144 (comment)

I can't explain the churn/changes without more research, but I think this has been touched a few times since the original PR. Since a single line fix should take care of it, I'll just knock it out right now and move on.

On the other one, it came in here ...

https://github.com/dotnet/AspNetCore.Docs/pull/17455/files#diff-aec5790e12a05d20a3cda92a708f6679R454

... and was approved here ...

#17455 (comment)

I'll fix both of these up right now.

[guardrex]

@SteveSandersonMS ... I see that Ryan had that assignment there, so it wasn't something that I changed after all. See down there at the bottom 👇. This code and the current version in the doc don't work without that assignment.

I was going to fix this tonight, but I've been up since 5am. Let me know how you would like this handled. I'll knock it out first thing in the morning.

<input
       type="@(ShowPassword ? "text" : "password")"
       required
       value="@Password"
       @oninput="@OnPasswordChanged" />
<a @onclick="ToggleShowPassword">
    Show password
</a>

@code {
    private string password;

    [Parameter]
    public string Password
    {
        get
        {
            return this.password ?? "";
        }
        set
        {
            if (this.password != value)
            {
                this.password = value;
            }
        }
    }

    [Parameter]
    public EventCallback<string> PasswordChanged { get; set; }

    bool ShowPassword { get; set; }

    private void ToggleShowPassword()
    {
        this.ShowPassword = !this.ShowPassword;
    }

    private Task OnPasswordChanged(ChangeEventArgs e)
    {
        Password = (string)e.Value;
        return PasswordChanged.InvokeAsync(Password);
    }
}

[guardrex]

UPDATE ... Ok, I think the rubber 🦆 has helped me understand where the text and examples went off the tracks. Ryan's sample didn't take the latest guidance into account, and I thought the problem with a component that writes to its own parameters had a more limited scope than it does. I think I see now how to fix the text and examples. PR coming soon! ... Stand-by!