Repository navigation
[1.0.2] Setting property treated as idempotent, but isn't #1768
Description
Activity
Actually... the observer at issue in the example above is
_updateSelected(attrForSelected, selected)- shouldn't that observer be correctly executed whenattrForSelectedhas it's value set tonullby the property default?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-changedlisteners set up by Polymer. In your example where you set up your ownon-data-changehandler 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-changehandler with anobserverfor the same property:
http://jsbin.com/xoqamu/2/editCan you confirm whether you can use this approach, and we'll close the issue?
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 :)
Originally raised this issue: PolymerElements/iron-selector#16 - but the root of that problem is more appropriate here. From that issue:
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.