Setting undefined properties via data binding

[Michael Giuffrida]

Some questions about what behavior is defined for data binding (and what's undefined behavior and should be avoided) when using properties which aren't actually defined.

https://jsfiddle.net/daLLdao2/

If I give a Polymer tag some-made-up-attribute="foo", nothing happens. But if I give that made-up attribute a value via data binding (some-made-up-attribute="[[myProperty]]"), the Polymer element gets a new someMadeUpAttribute property set to the value and type of myProperty. Is that okay, or should we not expect that to work?

It gets weirder: if I want to create a property and assign it to a literal, I can do this:

    some-made-up-attribute="[[notARealProperty]]my string literal"

the attribute someMadeUpAttribute is again created on the child, and given the string value "my string literal". Is that a fluke, or is data binding defined to work that way?

[Arthur Evans]

All of those things are working as intended. The important thing to understand is how Polymer uses attributes to set up data bindings.

If you set an attribute on an element, you're just setting an attribute:

    <foo-bar some-thing="blue">

**If** `foo-bar` is a Polymer element and its `someThing` property has property effects (like data bindings or observers) associated with it, Polymer will set the property value from the literal. We call this "configuring" the element, since it's a mostly static. If it's not a property that Polymer is concerned with, it gets left alone.

(It's not that _nothing_ happens here: getAttribute('some-thing') still returns 'blue'. But it doesn't touch the element's properties.)

However, Polymer also uses attributes to set up data bindings:

    <foo-bar some-thing="{{blue}}">

Think of it this way: as soon as we see that data binding annotation, this becomes a different thing: a property binding. When `blue` changes, Polymer pushes the change down to `foo-bar.someThing` (and vice-versa, since this is a two-way binding: when someThing changes, the change propagates up to `blue`).

Property bindings set the property regardless of whether `foo-bar` is a Polymer element or has a property called `someThing`. This lets us push arbitrary properties to native elements, for example.

Finally, for the compound binding, where you combine binding annotations with string literals, the defined behavior is for an undefined property to be replaced with the empty string. So "{{undefinedProp}}Foo" becomes "Foo". If you want different behavior—like conditionally printing "Foo" if and only if the property is defined, then you probably need a computed binding, instead.

-Arthur

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CACi5S_1%2BiB7SpHQkhEANxpvhe-4Dgp%3DYNnL%2BU%2Be0obHySi-3pA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ijaz786b...@gmail.com]

Data binding is the process that establishes a connection between the application UI and business logic. If the binding has the correct settings and the data provides the proper notifications, then, when the data changes its value, the elements that are bound to the data reflect changes automatically.

DataScience Training in Chennai