Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two-way bindings to array members not updating when data edited in dom-repeat template (bug or feature?) #1821

Closed
adalinesimonian opened this issue Jun 10, 2015 · 7 comments

Comments

@adalinesimonian
Copy link

Given some sort of input element within a dom-repeat template, if the element's value is bound to a member of the collection to which the repeating template is bound, the value of the collection's respective item will not update when the element has its value changed.

For example:

<dom-module id="record-card">
  <template id="node">
    <template is="dom-repeat" items="{{labels}}" observe="{{labels.*}}">
      <h1>
        <input is="iron-input" bind-value="{{item}}" on-input="labelChanged">
      </h1>
    </template>
    <input is="iron-input" bind-value="{{labels.0}}">
    Labels: <span>{{displayLabels(labels.*)}}</span>
  </template>
</dom-module>
<script>
Polymer({
  is: "record-card",
  properties: {
    labels: {
      type: Array,
      notify: true,
      value: function() {
        return ["Pizza", "Person"]
      }
    }
  },
  displayLabels: function(e) {
    return e.base.join(', ');
  },
  labelChanged: function(e) {
    console.log(e.model.item);
    this.set('item', e.model.item);
  }
});
</script>

The iron-input element bound directly to labels.0 functions as expected. It both a) updates when the value of labels[0] is changed, and b) updates the value of labels[0] when its own value is changed.

However, the iron-input elements inside of the template will not update the values of the array members when input is provided. They will update upon the array being mutated, though.

Live demo at http://jsbin.com/xuhitowiji/1/edit?html,output

@adalinesimonian adalinesimonian changed the title Two-way bindings to array members not updating when data edited in dom-repeat template (bug or feature?) iron-input's bind-value not functioning in dom-repeat template (bug or feature?) Jun 10, 2015
@adalinesimonian adalinesimonian changed the title iron-input's bind-value not functioning in dom-repeat template (bug or feature?) Two-way bindings to array members not updating when data edited in dom-repeat template (bug or feature?) Jun 10, 2015
@bvhme
Copy link

bvhme commented Jun 10, 2015

Thanks so much for adding this, It has really really been doing my head in. I guess this is a bug since the workaround would be to serialise the object into an array of objects.

How I'd love a solution for this!

@adalinesimonian
Copy link
Author

@bvhme Someone on SO found a workaround: http://stackoverflow.com/a/30760144/4220785

@bvhme
Copy link

bvhme commented Jun 10, 2015

@vsimonian Yeah, saw that, it only works if you have an Array of Objects, Strings won't work. This means serialising and deserialising objects when I get and send them with JSON, not ideal but will have to do. Thanks though!

@kevinpschaaf
Copy link
Member

This demo points out two issues that have been separately reported:

  1. Binding to specific element indicies directly such as {{labels.0}} is not currently supported (and may not be in the near term). Please see setting individual array elements not working #1854 (comment) for workarounds. In your example, since you actually want the upward-bound values to be propagated, using a computing function won't help here so I'd recommend forgoing binding and just using events here to call this.set(['labels', 0], e.target.value) in on-input.
  2. There is a bug in dom-repeat (bindings to concrete types not propagating correctly from template to collection #1839) where binding to an array of primitive values does not result in the underlying array values changing when the value changed in the element instance (sorry, your issue was opened first but we hadn't see it yet when that one was raised internally, but we'll go ahead and track the issue there)

Closing this, as we'll track the two issues separately

@adalinesimonian
Copy link
Author

Thanks for the pointers, @kevinpschaaf! I'll be keeping an eye on #1839

@itsff
Copy link

itsff commented Jun 16, 2015

No worries. Will be on the lookout for the fix

@bvhme
Copy link

bvhme commented Jun 16, 2015

Thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants