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
On Tue, May 10, 2016 at 3:34 PM, 'Michael Giuffrida' via Polymer <
[email protected]> wrote:
> 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?
>
> 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 [email protected].
> 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
> <https://groups.google.com/d/msgid/polymer-dev/CACi5S_1%2BiB7SpHQkhEANxpvhe-4Dgp%3DYNnL%2BU%2Be0obHySi-3pA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/CADSbU_xDwDSNQRokdORfbkv3urMogzcQVWiEB3pFYWQ3B%3D9JzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
