Properties not cleared when elements reused in dom-repeat.

[kevinpschaaf]

From @kayur on December 24, 2015 8:36

I'm trying to use dom-repeat to create a list of paper buttons, which have a custom attribute that I set. The html template for the custom element is a bit complicated but here is an example that illustrates the core issue:

<dom-module id="my-element">
  <template>
    <template is="dom-repeat" items="[[experiments]]">
      <paper-button label$="[[item.name]]">
        [[item.name]] the [[item.job]]
      </paper-button>
    </template>
  </template>
  ...

<my-element> has an property experiments which gets updated frequently with new data. experiments is used to generate a list of <paper-button> with a custom attribute label that's set to item.name.

Let's set experiments = [{ name: "joe", job: "plumber"}, { name: "cat", job: "maker"}]

Let's call the first paper button, button. I would expect button.getAttribute(label) === joe and button.label === undefined. That's not the case. Some magic sets button.label to joe. That's fine. It could be useful magic.

Now let's set experiments = [{name: "cat", job: "maker"}]. I would expect button.getAttribute(label) === cat, and indeed that's correct. But button.label === joe.

Why is this happening?

It feels like a bug because I'd expect reused elements not have zero state that indicates they were used for anything else before.

Here is a jsbin with this example:
http://jsbin.com/hetazocaye/6/edit?html,js,console,output

Strangely div does the right thing.
http://jsbin.com/rekavifozu/3/edit?html,js,console,output

Copied from original issue: PolymerElements/paper-elements#62

[kevinpschaaf]

Yes, this looks like a bug with the data configuration process Polymer uses to efficiently flow binding data to other Polymer elements at initial construction of the tree. It incorrectly passes attribute bindings as property data. This should be trivial to fix, such that the label property is always undefined in your paper-button example: http://jsbin.com/gonola/edit?html,console -- I assume this is what you would expect, yes?

[kayur]

Yes, that is what I would expect.

[jfrazzano]

Will this have a carry-over affect on the "for" property in the label. I just was wondering if the prop to atts initial config was intentional to keep the for attribute inline with the with the label and related input. I have been doing a lot of input work, so this could be an "over thinking moment on my part" but a similar issue happened with a paper-input fix a few weeks ago, so i thought it better to say something than just shhhh....