Binding initialization when model is null

[Justin Fagnani]

I came across the following code in Polymer the other day:

  // capture A's value if B's value is null or undefined,

  // otherwise use B's value

  function resolveBindingValue(oldValue, value) {

    if (value === undefined && oldValue === null) {

      return value;

    }

    return (value === null || value === undefined) ? oldValue : value;

  }

https://github.com/Polymer/polymer-dev/blob/master/src/instance/properties.js#L167

The last line is what interests me. From where this is called in bindProperty(), it means that if a model property being bound to is null, it's set to the element property. Otherwise the flow is from model to element by default, if the binding is not two way.

What's the reasoning behind this special initialization path? The behavior is a bit surprising to me. When my model's property that I'm binding to is null, I don't expect any special initialization behavior. Especially since null might be a valid value for the model property. This also makes all bindings potentially two way, even when you think you know that the element property you're binding to doesn't ever update.

Thanks,

  Justin

[Scott Miles]

When two properties are bound together we must merge two sources-of-truth into one, which entails inherent conflicts. The rule has always been that if one of the two properties is _valued_ (not null or undefined), then it becomes the new shared value, regardless of direction.

Recently we decided to also prevent transitions between undefined and null from being reported as `*Changed`. It's true this is a lossy change, but it prevents a lot of unwanted side-effects at construction time where various properties tend to be in either state, but are almost always indicative of an _uninitialized_ state.

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/CAEKsHmD-%2BMHFL3J%2BbRJEcG3WG3eZz90TPbaqj1rRPkX94CD7%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Günter Zöchbauer]

Great to hear. This caused me troubles in the past because there were often two calls to xxxChanged at startup when run in JavaScript 

while in Dart there was only one such call.

[Justin Fagnani]

On Mon, Jun 2, 2014 at 11:13 AM, Scott Miles <sjm...@google.com> wrote:

When two properties are bound together we must merge two sources-of-truth into one, which entails inherent conflicts. The rule has always been that if one of the two properties is _valued_ (not null or undefined), then it becomes the new shared value, regardless of direction.

I understand why undefined is considered not valued in JavaScript, but how come null is not? Null seems to be a completely valid value. I know that bindings are two-way by default, but they aren't really symmetric and I expect the data flow to be biased to go from model to element, so in this case I would expect the element property to be initialized to null.

Another issue is that not all expressions are assignable, and this behavior results in initialization trying to assign to non-assignable expressions and limits our ability to warn users.

Consider a binding like <x-foo a="{{ x + 1 }}">. If x is null, the expression is null, and initialization will try and fail to make the assignment x + 1 = a. We like to warn when assigning to a non-assignable expression, because if you write <input value="{{ x + 1 }}"> this is likely a mistake. But since any binding may now attempt to assign to an expression that warning becomes console spam. Now I think we are forced to remove that warning.