Parent polymer elements dont seem to react to change in children.

[santiago-elustondo]

tldr: When children of paper-dropdown-menu are updated by Angular, the parent does not reload or react to the change. The "selected" option does not bind to the new items, for example, unless we update it as well. The example code is available here: https://github.com/dirtysanchez69/issue-angular2-polymer

Say I have a paper-dropdown-menu, as such (this works fine):

//hardcoded options and selection

<paper-dropdown-menu label="hardcoded options and selection">
  <paper-listbox 
  [selected]="1"
  class="dropdown-content">
    <paper-item *ngFor="let option of ['hi', 'hello', 'yo']">{{option}}</paper-item>
  </paper-listbox>
</paper-dropdown-menu>

In this case, the child (paper-item) is presumably parsed before the parent (paper-listbox), and the parent selects the second of its children to be the selected value.

Now, if the options arrive a bit later, after an async event, the options (paper-items) are updated just fine, but we lose the selected value.

//hardcoded selection

<paper-dropdown-menu label="hardcoded selection">
  <paper-listbox 
  [selected]="1"
  class="dropdown-content">
    <paper-item *ngFor="let option of dropdownOptions.fruit">{{option}}</paper-item>
  </paper-listbox>
</paper-dropdown-menu>

If dropdownOptions.fruit is initialized with some values, we see the selected value, but upon updating them, the selected value disappears.

Now, if we also bind the selected value, and we update that as well upon receiving the new data, then the new selected value is displayed (hooray). However, this only works if we actually change the value of the "selected" property. If we initialize this value to 1, then we must pick another number in order to trigger the update (which still leaves us with a problem).

<paper-dropdown-menu label="selection refresh" #fruitDropdown >
  <paper-listbox 
  [selected]="userData.fruitSelection"
  class="dropdown-content">
    <paper-item *ngFor="let option of dropdownOptions.fruit">{{option}}</paper-item>
  </paper-listbox>
</paper-dropdown-menu>

What do you think of this?
Is there a clean way to forcibly trigger a reload on a polymer element?

[platosha]

Hi! This indeed looks like our bug. Two things I found so far that might be helpful:

1. Your example code works fine in native shadow DOM mode. Open your app in Chrome and add the ?dom=shadow query string to the URL).
2. This use case seems to work in general, without Angular: http://codepen.io/platosha/pen/LZWxqb?editors=1010

Probably a bug in PolymerShadyDomAdapter. Will investigate more.

About triggering the property change effects, I think that changing the property value to something else and back to the desired value is the only way to trigger them. There is a check for the value change that sets this requirement in the _notifyPath method of Polymer.Base, see: https://github.com/Polymer/polymer/blob/master/src/standard/notify-path.html

[santiago-elustondo]

Thanks!

[platosha]

Further research findings: the issue is probably caused by the fact that in PolymerShadyDomAdapter we call Polymer.dom.flush(); on every change. After I removed these calls, the example code by @dirtysanchez69 started to work as expected.

The reason I think of is: when changing the menu options with binding, Angular 2 removes the DOM nodes before adding the new ones. Calling Polymer.dom.flush(); after each node removal might trigger pending MutationObservers. Therefore, iron-items-changed events are fired multiple times on each add/remove, instead of just once after a couple the changes. That makes the listbox think that, at some point, there is no selected item, so it resets the internal selected property to some fallbackSelection.