[1.0.2] Setting property treated as idempotent, but isn't

[hawkett]

Originally raised this issue: PolymerElements/iron-selector#16 - but the root of that problem is more appropriate here. From that issue:

• JSBin demonstrating the problem
• JSBin demonstrating the preferred approach/solution

The first jsbin still highlights some issues though. Basically, when setting a property value, polymer checks the current value, and does a no-op if they're the same (i.e. assumes idempotence). However, in situations where one of the values a complex observer depends on is undefined, the observer is not executed. Subsequent attempts to set that same value are no-op'd and the observer is never called, despite the property having been set.

[hawkett]

Actually... the observer at issue in the example above is _updateSelected(attrForSelected, selected) - shouldn't that observer be correctly executed when attrForSelected has it's value set to null by the property default?

[kevinpschaaf]

There is special handling in the data layer to queue data notification handling from clients in a given element until all of its clients (local DOM custom elements) have initialized. This happens for free when using things like observers that run based on data-changed listeners set up by Polymer. In your example where you set up your own on-data-change handler manually, this queueing does not happen, and so (as you pointed out), you end up setting values to one of the children before it has initialized (which is bad).

Probably the easiest option is to simply "use the system", as in the following jsBin, where I've replaced your on-data-change handler with an observer for the same property:
http://jsbin.com/xoqamu/2/edit

Can you confirm whether you can use this approach, and we'll close the issue?

[hawkett]

Yep, can confirm - that's equivalent to the second jsbin I posted (preferred approach/solution).

The "Don't use events, use observers" pattern is definitely one to hang onto :)