Provide motivation for bind modifiers

[guardrex]

Per @lonix1 on original issue #28245 ...

In this section it says:

For two-way data binding in ASP.NET Core 7.0 or later, we recommend using @Bind:get/@Bind:set modifiers. For more information, see the @Bind:get/@Bind:set in the opening section of this article.

But it doesn't say why? I assume that the new v7 syntax allows one to perform a "set" with an async method, which cannot be done using a regular c# (sync) property setter. That is useful, for e.g., when doing autocomplete. Maybe there are other reasons?

Cross-references:

• Design proposal: Multiple same-named event handlers aspnetcore#39815
• Design proposal: Bind get/set/after modifiers aspnetcore#39837
• Support @bind:get, @bind:set, @bind:after razor-compiler#70
• Blog post (Release): "Run async logic after data binding and independently control how data binding gets and sets the data."
• Blog post: (Preview 7): "now easier to setup binding" and "now make it trivial to create a component parameters that binds to an underlying UI element"

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: b211df59-e1c9-86c0-c904-31fa3c361e6d
• Version Independent ID: 3f912dfc-5ba5-6c6c-ba93-1ae78508a5cc
• Content: ASP.NET Core Blazor data binding
• Content Source: aspnetcore/blazor/components/data-binding.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

@lonix1 ... It looks like from Javier's remarks that only one specific reason ... well, that's obvious anyway because dev issues that were opened for the PU aren't listed in the design issue ... the one specific reason that applies to the remark is ...

Or, if you @bind to a property with a get/set pair, you have to discard the Task returned by ValueChanged.InvokeAsync.

Cross-ref: dotnet/aspnetcore#39837

... noting that the example in THIS article's section doesn't bind to a property ... we do it down in the Bind across more than two components section ... which actually has a whole different approach with @bind:get/@bind:set commented out that nobody can see due to problems with the feature at the time of .NET 7's release that were partially fixed by a framework patch and will be completely fixed in VS for the February VS release. The update to that doc section is tracked by a separate issue, which I'll work as soon as the new VS drops and the PU confirms that VS is cool ... the problem in VS btw AFAIK was just that IntelliSense is tripping up on the syntax. I think the runtime is cool ... I think it's just a UI problem in VS.

I think that I should say in the NOTE the one reason that we do have ☝️. Let's do that. I'm not convinced that we should cross-link the whole design issue at this point. I'll take more feedback on that. If more devs ask about the motivations for the change and want to read further, I'll give them the link to that PU issue at first ... and if folks keep asking, I'll cross-link that PU issue into the document in the earlier section that introduces the main concepts.