polymer: dom-repeat doesn't call `_render` when an item changes
Description
If you have a sorted dom-repeat and a change occurs to an item (such that the path is like items.#2), then _render will not be called internally (because of this).
This seems to be because it assumes any path which isn’t items or items.splices must be a sub-property change, and thus should follow through to the logic for the observe property.
However, not all other paths are sub-property changes, clearly. Some can be of the form items.#2.
Should this not trigger a re-render? Or somehow check if the properties defined in observe have changed?
Live Demo
http://plnkr.co/edit/fACxm4GDp1RsLKerazjW?p=preview
Clicking the button will set one of the children to a new object, causing a items.#2 change notification.
As you can see, a workaround is in this demo, the observer manually calls render() if you uncomment it.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 23 (16 by maintainers)
Commits related to this issue
- fix dom-repeat sort on item update Fixes #3626 by triggering a render when a single item changes in a sorted/filtered dom-repeat. — committed to 43081j/polymer by 43081j 8 years ago
- Fix conditions when dom-repeat needs to re-sort or re-filter. * For efficiency do not process `items.length` changes * Ensure observing `foo` is not triggered by a `foobar` etc. * Ensure assignments ... — committed to kaste/polymer by kaste 8 years ago
- Fix conditions when dom-repeat needs to re-sort or re-filter. * For efficiency do not process `items.length` changes * Ensure observing `foo` is not triggered by a `foobar` etc. * Ensure assignments ... — committed to kaste/polymer by kaste 8 years ago
- Ensure re-sort/filter always happens after array item set. Fixes #3626 — committed to Polymer/polymer by kevinpschaaf 7 years ago
- Merge pull request #4942 from Polymer/3626-kschaaf-repeat-refresh Ensure re-sort/filter always happens after array item set. Fixes #3626 — committed to Polymer/polymer by deleted user 7 years ago
I’m inclined to agree with @kaste here.
this.set(array.#1, newItem)is essentially a splice operation, and I think it should be handled that way, but instead it re-uses the existing key:https://github.com/Polymer/polymer/blob/1b02e96e77a0ef201976341fade763c617eca0d5/src/standard/notify-path.html#L179
Tagging @kevinpschaaf to review and comment. I don’t know if this is short-term fixable or if we need to tell people to use
this.spliceas a workaround in the near term. (In particular, apparently firebase-collection doesthis.set('array.#key', newitem)so if this isn’t going to be fixed in core it should be patched over there.)