Blazor automatic arbitrary attribute binding ... Is it a thing?

[guardrex]

@javiercn ... This can be addressed later, after RC1 lands. I've temporarily pulled my errant content+example from the doc, so there's no rush on resolving this. I'll ping u back later this month if this isn't clarified by someone before then.

Is automatic arbitrary attribute binding a thing?

I searched and didn't quite find a matching issue, although #24916 has similar aspects.

I'm working on a doc update, and any of the following are possible:

• I misunderstood a framework behavior for binding to arbitrary attributes.
• I made something up that doesn't exist. (Most likely! 🙈)
• There's a 🐞 in the framework ... perhaps [Blazor] Cannot bind custom checkbox element's checked value #24916 is the same issue.

NOTE ... For the following examples, I understand that I can accomplish the behaviors that I expect by assigning fields/properties directly to attributes ...

<input data-info="@val" @bind="val" @bind:event="oninput" />

... but that's not what I'm asking about. I'm asking about automatic Blazor binding behavior for arbitrary attributes, if any such behavior exists ...

<input @bind-data-info="val" @bind-data-info:event="oninput" />

Consider this example for an arbitrary data-info attribute on an <input> element:

<input @bind="val" />

<input @bind-data-info="val" @bind-data-info:event="oninput" />

<p>
    val: @val
</p>

@code {
    private string val = "1";
}

Load behavior

The value of data-info is set to 1. Unexpected, since I thought it would only be bound if the second <input>'s oninput event fired.

Behavior of the first input

Change the first <input> (type a 2) and change the element's focus to trigger an onchange and update to val:

The value of data-info is updated. Ok ... but again ... I was expecting the second <input>'s value to only be updated when the second <input>'s oninput fires.

Behavior of the second input

Type a value into the second <input>, which will fire its oninput event:

The value of val is changed. I didn't think I was binding val to value of the second <input>. I thought that I was only binding val to the data-info attribute. Note also that data-info isn't updated in this case in spite of val being updated, which is at odds with updating val via the first <input> element as shown previously ☝️.

Conclusion

These behaviors seem to indicate that ...

That's not a thing. You just made that up. — David Fowler, 2016

Can someone ...

• Confirm that all of my expectations are wrong by-design. If so, then these types of arbitrary attribute "bindings" should be done via direct assignment ... like ...

  <input data-info="@val" @bind="val" @bind:event="oninput" />

• Explain the behavior of automatic arbitrary attribute binding (i.e., non-value binding in this case) ... like ...

  <input @bind-data-info="val" @bind-data-info:event="oninput" />

• Or ... I suppose it's possible that there are some framework in-design/changes coming for this type of binding behavior.

After I hear back, I'll be able to update the Binding doc with the correct guidance on dotnet/AspNetCore.Docs#19721.

[guardrex]

@mkArtakMSFT ... I didn't want to make too much noise about this given that it seems much less important than the .NET 5 work. Should this be left here ... or moved to the engineering repo ... or just closed†? There was doc content pertaining to this "feature†" that I've had to pull until we find out if and how this works.

†I say "closed" and "feature" because I may have totally made this up. 🙈 I may have misinterpreted some engineering remarks. The content was approved, but it was buried in a whole bunch of other changes, thus it may have slipped in accidentally. Anyway, I pulled the content; so if I did make this up, we don't need to make doc changes. I would only need to close my docs issue, and you can mark this discussion as "answered."

UPDATE: I've asked if Steve will put an 👁️ on this just to confirm that I made this up! If I did, we don't need to take further action. I've already pulled the content. All I need to do is close the original issue as fixed.

[SteveSandersonMS]

About this:

<input @bind-data-info="val" @bind-data-info:event="oninput" />

Yep, there's no such feature, and never has been 😄 People should indeed use the actual binding feature that does exist, and can independently render data onto any attribute, like in your other example:

<input data-info="@val" @bind="val" @bind:event="oninput" />