Reset for dynamically added elements

[200Puls]

Description

Hi @notwaldorf and @valdrinkoshi, thanks for merging the other 2 PRs. I have encountered another small issue with iron-form when parts of a complex form are lazily added by the dom-if element.

In this case the default values are not saved because the elements are not there when saveInitialValues is called.

Expected outcome

Values of dymically added elements should be reset.

Actual outcome

Values of dynmically added elements are not reset.

Live Demo

In this demo a dynamic element is added after about 1.5 seconds. When the form reset is triggered the value is not reset:

https://output.jsbin.com/foyuquwaru/ https://jsbin.com/foyuquwaru/edit?html,output

Steps to reproduce

Browsers Affected

• [x] Chrome
• [x] Firefox

[200Puls]

I have experimented with two implementations to solve this:

• add this.addEventListener("dom-change", this._saveInitialValues.bind(this)); in _init dom-change is fired by dom-if and dom-repeat. Therefore it works perfectly for those. It works if changes occur which are not caused by direct children of the form

• Polymer.dom(this_form).observeNodes( function(mutations) { this._saveInitialValues.bind(this)}) This works only for direct children of then form. But any dom changes are recognized.

I'm currently favoring the first solution and have prepared a PR for this...

[notwaldorf]

I'm not sure this fix should live in here. Generally, the iron-form shouldn't need to care about who its parent is, and the fact that it is a dom-if is just an implemetation detail. I think you should maybe as a workaround do the this.addEventListener("dom-change", myForm._saveInitialValues()); call inside your app.

[200Puls]

I see your point. Although this issue is not about the parent of the form but the child elements. So if any child element in the form is dynamically rendered by dom-if:

`

`

The reason why I thought it might be the correct playce is that iron-form already knows a lot of how to find the correct elements. So being notified about new elements seemed natural.

[JaySunSyn]

@notwaldorf this might also solve the issue if form elements are rendered via dom-repeat. Right now, _saveInitialValues is being called async on attach. However, its called before the elements of dom-repeat are rendered...

<iron-form>
  <form>
    <template is="dom-repeat" items="formItems">
      <template is="dom-if" if="[[_equal(item.type, 'input')]]">
         <paper-input></paper-input>
      </template>
    </template>
  </form>
</iron-form>

Imo scenarios like above should be handled here rather than calling a private method of iron-form from the app ...

[notwaldorf]

Rather than adding this code to the iron-form (since I am not convinced that it's the iron-form's responsibility to know how its elements are stamped, nor really a feasible and cheap alternative to always look for all dom changes) , we're adding a public saveResetValues method.