Add 'bind-...' for two-way binding #16307

rynowak · 2018-03-28T00:10:28Z

Summary

We're adding a feature that replaces @bind(...) with something more first class for tooling.

Introducing bind-... for two-way binding:

<input bind="@CurrentValue" />
@functions {
    public string CurrentValue { get; set; }
}

bind-... attribute implements two-way binding to components and dom elements via a tag helper with special compile-time behavior. This means that intellisense, colorization, and completion know about bind-... and can provide contextual documentation and contextual completion.

note: the correct date format is actually yyyy-MM-dd. Do as I say, not as I do 😆

What is two-way binding?

If you're not familiar with @bind (the thing being upgraded), this does two-way binding to both components and dom elements. This is like a macro, it doesn't do anything you couldn't do normally, but it should help you out 👍

Example:

<input bind="@CurrentValue" />
@functions {
    public string CurrentValue { get; set; }
}

Generates something like:

<input value="@CurrentValue" onchange="@((__value) => CurrentValue = __value)/>
@functions {
    public string CurrentValue { get; set; }
}

This means than when the component first runs, the value of the input element will come from the CurrentValue property. When the user types in the textbox, the CurrentValue property will be set to the changed value. This is why we call it two-way binding.

In reality the code generation is a little more complex because bind deals with a few cases of type conversions. But in principle, bind-... will associate the current value of an expression with a value attribute, and will handle changes via a change handler attribute. We expect to invest more in the runtime support in this area in the future, including better conversion, error handler, etc.

One additional point, the expression provided to bind-... should be an LValue, meaning that it's something that can be assigned. Since this is code-generation, it works in places that the C# ref keyword doesn't work.

React can do something similar: https://reactjs.org/docs/two-way-binding-helpers.html

Use cases

DOM elements

The most obvious usage of bind-... is for input elements of various types. You're going to have lots of these 😆

That looks like this:

<input bind="@CurrentValue" />
@functions {
    public string CurrentValue { get; set; }
}

Or this:

<input type="checkbox" bind="@IsSelected" />
@functions {
    public bool IsSelected { get; set; }
}

For cases like this, we have a set of mappings between the structure of an input tag and the attributes that we need to set of the generated dom elements. These mappings are driven by attributes defined in code and are extensible.

Right now this set is minimal, but we plan to provide a good set of mappings out of the box for completion to lead you down the right path.

Format strings

You can also provide a format string - currently only for DateTime values.

<input type="date" bind="@StartDate" format="yyyy-MM-dd" />
@functions {
    public string StartDate { get; set; }
}

The format string will be used to convert to and from .NET values to the DOM attributes. We plan to enhance this area in the future, currently it's restricted to DateTime. If you use this with an expression that isn't a DateTime, expect some fireworks 🎆

Components

bind-... can also enhance components by recognizing component attributes that follow a specific pattern.

That looks like:

@* in Counter.cshtml *@
<div>...html omitted for brevity...</div>
@functions {
    public int Value { get; set; } = 1;
    public Action<int> ValueChanged { get; set; }
}

@* in another file *@
<Counter bind-Value="@CurrentValue" />
@functions {
    public int CurrentValue { get; set; }
}

The code generation for components is a little plainer. Since you're calling into .NET code from .NET code, we expect the types to match.

Note that the component author doesn't have to do anything special to enable this, we detect the bindables based on the names and types of the component properties.

Bind, user-defined

If you have a use for it, you can define your own mappings for bind-... and do things like this:

// in BindAttributes.cs
[BindElement("ul", "foo", "myvalue", "myevent")]
public class BindAttributes
{
}

@* in MyComponent.cshtml *@
<ul bind-foo="@SomeExpression" />

Bind, general case

bind-... also supports a fallback case that totally flexible. You can specify bind with any value attribute name and change handler attribute name.

<ul bind-myvalue-myevent="@SomeExpression" />

This will bind the current value of @SomeExpression to myvalue and a change handler lambda to myevent.

Next steps

The first change here introduces the general concept of bind as a language feature rather than a function call. I think that this works well for the cases that we have tested with @bind, but we need to do more work in the runtime to make it really complete.

This includes:

support conditional attributes
extend the set of bind-... mappings we provide by default
improve support for conversions
improve error handling for conversion failures

One of the next things we do will be to give the same treatment to @onclick and extend the set of default mappings we provide for event handlers.

There's also a master list of improvements to the programming model for components described here: https://github.com/aspnet/Blazor/issues/1

That list doesn't have much detail is only a general outline.

The text was updated successfully, but these errors were encountered:

schotime · 2018-03-28T02:37:23Z

We should also ensure that using a single state store like the FlightFinder demo does works just as well.

If you auto bind to a property then another component depends on that property to render, it does not get re-rendered because you haven't fired the StateHasChanged() event. And thats pretty hard to do without getting into ugly stuff like the below.

<input class="toggle" type="checkbox" @bind(completed) />

@functions
{
    bool completed
    {
        get { return state.Todos[Id].Completed; }
        set { state.Todos[Id].Completed = value; StateHasChanged(); }
    }
}

darilek · 2018-03-28T08:20:24Z

IMHO these custom attributes (bind, format, converter, ...) should be prefixed to distinguish them from the standard HTML attributes

muqeet-khan · 2018-03-28T14:59:42Z

@rynowak I am trying to understand if there is a way for bind to provide ''bindable" data to the compnents ChildContent?

Think of this scenario, for example:

@* Consumer is sending raw data to the component for "processing" *@
<MyStockExample bind-rawstockdata="@rawStockData" bind-processedstockdata="@processedData">
    <textarea rows="5" >
           @processedData
    </textarea>
</MyStockExample>


@functions{
    public ProcessedStockData processedData { get; set; }
    public RawStockData rawStockData { get; set; }
}

Wherein, MyStockExample is taking in RawStockData and then "processing" it and providing it as a bindable object to its child content as (ProcessedStockData) so that the consumer can then use that data without having to depend on the component author.

The question is would the above be possible with this change? If no, is this approach not the right one in context of Blazor components?

rynowak · 2018-03-28T15:13:06Z

@muqeet-khan - you don't need bind for that case because it's not two-way, and not changing.

We plan to address this scenario also in the future.

danroth27 · 2018-03-28T17:58:20Z

@guardrex

awulkan · 2018-03-28T20:43:56Z

If this requires manual work to update the DOM after a programmatic change to the property then it's not two-way binding imo. It will confuse a lot of devs coming over from other frameworks. It will also make the code harder to maintain in many cases.

All definitions I can find of two-way binding specify an immediate automatic update of both the rendered output and the stored value upon change, in both directions.

Or are there plans to also implement an auto-propagating two-way binding alternative?

bdparrish · 2018-03-29T06:29:58Z

<input value="@CurrentValue" onchange="@((__value) => CurrentValue = __value)/>

The code should be moved to JavaScript or the @functions section. Leaving in the HTML will make it difficult to debug in the Devloper Tools. It also clutters the HTML.

jonathanperis · 2018-03-29T10:21:34Z

Why not asp-bind like aspnet core existing tag helpers for consistency reasons?

tdinucci · 2018-03-29T10:59:26Z

I personally prefer this new "bind-" syntax to the @Bind previously. However is there even a need for the "bind-*" syntax?

I personally think Polymer has a very nice model for bindings.

To me the following transformation doesn't feel intuitive - what does "bind" bind to?. Is it "value", or "id", or "type", etc

<input bind="@CurrentValue" />

to

<input value="@CurrentValue" onchange="@((__value) => CurrentValue = __value)/>

If something like the Polymer syntax were used though then the binding is unambiguous:

<input value="{{CurrentValue}}"/>

I also wonder if things like string formatting (from top post):

<input type="date" bind="@StartDate" format="yyyy-MM-dd" />

Could be achieved with the string interpolation syntax. With the syntax below I don't have to learn anything Blazor specific, I can just use my existing HTML and C# knowledge:

<input type="date" value="@StartDate:yyyy-MM-dd"/>

To take things a little further, the binding syntax could be augmented to signify one/two way bindings. Polymer syntax is:

One-way:

<input value="[[CurrentValue]]"/>

Two-way:

<input value="{{CurrentValue}}"/>
I'm in no way suggesting that you do exactly the same thing as Polymer, I just think there syntax has a lot of nice aspects.

rynowak · 2018-03-29T17:41:46Z

The code should be moved to JavaScript or the @functions section. Leaving in the HTML will make it difficult to debug in the Devloper Tools. It also clutters the HTML.

@bdparrish - this is an example of the what the generated code looks like, it's not something we should suggest anyone write.

bdparrish · 2018-03-29T17:58:38Z

@rynowak

I understand that. I know that the code is simple but code needs to be separated from the presentation.

Also if the generated code looks like that, then it makes it difficult to debug those parts of the HTML.

krynium · 2018-03-29T23:08:03Z

Aurelia binding syntax is very intutive, why cant blazor use similar.

http://aurelia.io/docs/binding/basics

iAmBipinPaul · 2018-03-30T02:46:26Z

Auerlia data binding syntax is more descriptive and describes it's purpose.

http://aurelia.io/docs/binding/basics#html-and-svg-attributes

rynowak · 2018-03-31T00:12:31Z

Closing this issue as this feature was introduced with 4407de18baac1ad715549b26d292daa1d2fc3658

Thanks for the feedback and discussion on this topic. We chose this style because it feels very Razor and we're already working with something established (server-side Razor).

@OnClick

This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.

@OnClick

This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.

@OnClick

This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.

@OnClick

This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.

estomagordo · 2018-06-10T09:16:27Z

Excuse a silly question, but what is the role of the Action in the Counter example? What exactly is required to bind to values in a component?

Andrzej-W · 2018-06-10T14:03:10Z

Without Action you have only one way data binding. Also take into account that information in this post is a little outdated. Please read this in the doc:
https://blazor.net/docs/components/index.html#component-parameters
and example you are looking for is below Components attributes subheading.

@OnClick

This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.

McHeff · 2019-02-21T12:30:19Z

Is there a list somewhere that shows the different type's of bindings for different types of controls?

danroth27 · 2019-02-21T23:56:34Z

@McHeff Take a look at https://docs.microsoft.com/en-us/aspnet/core/razor-components/components?view=aspnetcore-3.0#data-binding and see if it answers your questions.

McHeff · 2019-02-22T07:05:45Z

@McHeff Take a look at https://docs.microsoft.com/en-us/aspnet/core/razor-components/components?view=aspnetcore-3.0#data-binding and see if it answers your questions.

Thanks @danroth27, I've already looked at that page, what I was looking for is like a list of all available types of bindings... Working with Blazor is fun, but I was looking for different types of bindings across different types of controls.

Example. checkboxes have "bind" as well as "bind-value-changed" I believe, so I was wondering what other types there are as intelisense doesn't show them...

Anyways, thanks for the reply man!

Oh, and if you're interested Dan, I've made a discord server for Blazor: https://discord.gg/Xg9ja5s

sipi41 · 2019-07-17T03:19:42Z

I was going crazy with this! the book was saying we should use like this:
<input type="text" bind="@variable" />
but the proper usage should be:
<input type="number" @bind="@variable" />

phongn105 · 2019-08-02T16:53:03Z

kudos sipi41. I got "Missing attribute name" @variable but still works.

danroth27 assigned rynowak Mar 28, 2018

rynowak closed this as completed Mar 31, 2018

mkArtakMSFT transferred this issue from dotnet/blazor Oct 27, 2019

mkArtakMSFT added the area-blazor Includes: Blazor, Razor Components label Oct 27, 2019

ghost locked as resolved and limited conversation to collaborators Dec 4, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add 'bind-...' for two-way binding #16307

Add 'bind-...' for two-way binding #16307

rynowak commented Mar 28, 2018

schotime commented Mar 28, 2018 •

edited

Loading

darilek commented Mar 28, 2018

muqeet-khan commented Mar 28, 2018

rynowak commented Mar 28, 2018

danroth27 commented Mar 28, 2018

awulkan commented Mar 28, 2018 •

edited

Loading

bdparrish commented Mar 29, 2018

jonathanperis commented Mar 29, 2018

tdinucci commented Mar 29, 2018

rynowak commented Mar 29, 2018

bdparrish commented Mar 29, 2018

krynium commented Mar 29, 2018

iAmBipinPaul commented Mar 30, 2018

rynowak commented Mar 31, 2018

estomagordo commented Jun 10, 2018

Andrzej-W commented Jun 10, 2018

McHeff commented Feb 21, 2019

danroth27 commented Feb 21, 2019

McHeff commented Feb 22, 2019 •

edited

Loading

sipi41 commented Jul 17, 2019 •

edited

Loading

phongn105 commented Aug 2, 2019

Add 'bind-...' for two-way binding #16307

Add 'bind-...' for two-way binding #16307

Comments

rynowak commented Mar 28, 2018

Summary

What is two-way binding?

Use cases

DOM elements

Format strings

Components

Bind, user-defined

Bind, general case

Next steps

schotime commented Mar 28, 2018 • edited Loading

darilek commented Mar 28, 2018

muqeet-khan commented Mar 28, 2018

rynowak commented Mar 28, 2018

danroth27 commented Mar 28, 2018

awulkan commented Mar 28, 2018 • edited Loading

bdparrish commented Mar 29, 2018

jonathanperis commented Mar 29, 2018

tdinucci commented Mar 29, 2018

rynowak commented Mar 29, 2018

bdparrish commented Mar 29, 2018

krynium commented Mar 29, 2018

iAmBipinPaul commented Mar 30, 2018

rynowak commented Mar 31, 2018

estomagordo commented Jun 10, 2018

Andrzej-W commented Jun 10, 2018

McHeff commented Feb 21, 2019

danroth27 commented Feb 21, 2019

McHeff commented Feb 22, 2019 • edited Loading

sipi41 commented Jul 17, 2019 • edited Loading

phongn105 commented Aug 2, 2019

schotime commented Mar 28, 2018 •

edited

Loading

awulkan commented Mar 28, 2018 •

edited

Loading

McHeff commented Feb 22, 2019 •

edited

Loading

sipi41 commented Jul 17, 2019 •

edited

Loading