Inconsistent behavior with property values and defaults when creating custom elements inside a dom-repeat template

[punzki]

I've tried to capture all the weird behavior I've observed/experimented with in this JS Bin: http://jsbin.com/ciluco/1/edit?html,console,output

• repeat-me is a custom element with Boolean, Number, Array, and Object properties with default values
• i-repeat is a custom element that has a dom-repeat on an Array of Objects to create repeat-me elements in its local DOM
• I have instances of repeat-me by themselves, and also an instance of i-repeat which creates the repeat-me in its local DOM

Observed inconsistent behavior:

1. The default value for the Boolean and Number property are used when repeat-me is standalone, but not used when in i-repeat. The default value function for the Array and Object properties are used in both cases. See console output for "repeat-no-foo-bar" and "single-no-foo-bar" elements.
2. When passing in incorrect data types for properties. When repeat-me as standalone, Polymer makes a "best effort" to try to create the Boolean and Number property (Number is a NaN value), but not for the Object and Array property (they can become primitive data type properties). The behavior is opposite in i-repeat: The Boolean and Number properties change data types (they become Strings), whereas the Object and Array properties fall back to their default values. See console output for "repeat-data-type-mismatch" and "single-data-type-mismatch" elements.

Behavior number 1 doesn't seem to be a problem when I change i-repeat to accept an Array of primitives: http://jsbin.com/neyuco/1/edit?html,console,output

[kevinpschaaf]

Thanks for the detailed repro.

For (1), the case of using the element standalone differs from the i-repeat case in that the i-repeat case has bindings to the properties which take precedence over the default values; bindings always push their values when the root property is set, which in this case is undefined. This recently came up in another context, so we'll track that part of the issue here: #1877

For (2), Polymer only uses type as a hint to deserialization, not as a validator. Array and Object types simply use JSON.parse to get their values, hence valid values appearing for those (primitive values are valid JSON). We'll keep this issue open to consider warning when the resulting parsed value is not Array or Object; the Boolean & Number behavior is expected and will likely remain unchanged.

[punzki]

For (2), my main concern is that the deserialization of mismatched data types works differently in a standalone element than when it is bound to object properties (i.e., in a dom-repeat). As mentioned before, Polymer uses type as a hint with a standalone element.

But when bound to object properties, the behavior is a bit... wild? Boolean and Number properties are "clobbered" by the type of the object property -- I guess that's okay, because it's not the same as deserializing an attribute value. But Array and Object properties simply fall back to the property default value, not even clobbered, which I think is probably a bug somewhere.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed after being marked stale. If you're still facing this problem with the above solution, please comment and we'll reopen!