Add method to indicate an event handler should enforce value consistency

[SteveSandersonMS]

In other words, a way to tell Blazor that a given event handler is part of a two-way binding even if you're not using @bind.

It would probably look like this:

<input value="@MyValue" @onchange="MyHandler" @onchange:enforceConsistency />

... or maybe @onchange:sync or @onchange:twoWay. The implementation is simply to emit a builder.SetUpdatesAttributeName call for whatever is the "value" attribute for this element type (e.g., on <input type=checkbox> it would call builder.SetUpdatesAttributeName("checked");).

For more details about the scenario and justification for this design, see #17099 (comment)

[JvanderStad]

The @onchange event handler receives a Microsoft.AspNetCore.Components.ChangeEventArgs instance.

namespace Microsoft.AspNetCore.Components
{
    //
    // Summary:
    //     Supplies information about an change event that is being raised.
    public class ChangeEventArgs : EventArgs
    {
        public ChangeEventArgs();

        //
        // Summary:
        //     Gets or sets the new value.
        public object Value { get; set; }
    }
}

Can't we use the Value-setter to reflect changes?

public void ChangeEvent(ChangeEventArgs args)
{
	args.Value = "new value";
}

[hultqvist]

Could you also look into a scenario where the value is modified elsewhere, for example in a form submit method. The change in MyValue won't be related to the @onchange event.

[hultqvist]

I'm looking for a workaround.
This one appears to work though there's some magic in there.

async Task MyHandler(ChangeEventArgs args)
{
    var old = Text;
    Text = args.Value as string;
    await Task.Delay(1); //Magic!
    Text = old;

[thalaeg]

@hultqvist I know its a little late, but you can do a get and set with a private variable like this illustrates
https://stackoverflow.com/questions/60378477/filter-blazor-input-field

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[JvanderStad]

Looking forward to this one!

[danroth27]

@SteveSandersonMS Do we still need this now that we have get/set/after?

[javiercn]

@SteveSandersonMS I believe this is handled, if not, feel free to reopen