Change Detection Quirk with NgForm.resetForm()

[jongunter]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Right after calling resetForm() on an instance of NgForm (to clear out validation and mark everything as pristine) I then change a value that one of form controls is bound to (using template-driven forms and ngModel). The control does not update with the new value, but instead gets stuck with the null value that resetForm() sets on it. This only happens if the control is untouched.

Expected behavior

Change detection should pick up the change I make to the ngModel-bound variable after calling resetForm().

Minimal reproduction of the problem with instructions

Using the example below

1. Fill out the name field
2. Choose "Yes"
3. Press "Submit".
4. The form should reset and the dropdown should revert to "No", as expected.
5. Fill out the name field again
6. Choose "No"
7. Press "Submit"
8. The form should reset, but the dropdown is reverted to an empty value, rather than "No"

import {Component, ViewChild} from '@angular/core';
import {cloneDeep} from 'lodash';
import {NgForm} from '@angular/forms';

class User {
  isHappy = false;
  name = '';
}

@Component({
  selector: 'app-root',
  template: `
    <form #myForm="ngForm" (ngSubmit)="submit()">
      <div class="form-group">
        Name
        <input [(ngModel)]="user.name" name="name">
      </div>

      <div class="form-group">
        Are you happy?
        <select [(ngModel)]="user.isHappy" name="isHappy">
          <option [ngValue]="true">Yes</option>
          <option [ngValue]="false">No</option>
        </select>
      </div>

      <button type="submit">
        Submit
      </button>

      <pre>
    {{ user | json }}
  </pre>

    </form>

  `,
  styleUrls: ['./app.component.css']
})
export class AppComponent {

  user = new User();

  @ViewChild('myForm') myForm: NgForm;

  submit(){
    console.log('submitted', cloneDeep(this.user));
    this.myForm.resetForm();
    this.user = new User();
  }

}

What is the motivation / use case for changing the behavior?

The behavior is confusing. Even if we don't change Angular's response, it should probably be documented somewhere.

Environment

Angular version: 4.4.5

Browser:
- [ x] Chrome (desktop) Version 61.0.3163.100 (Official Build) (64-bit)
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

[jongunter]

I should mention that if I call

this.myForm.resetForm({ isHappy: false });

This issue does not appear. The problem is that

this.user = new User();

should always set the isHappy control to false, right?

Also, I said

This only happens if the control is untouched.

I was wrong. Actually, it seems to happen if the control's value is false when resetForm() is called, regardless of if the control it touched/pristine or not. If the control's value is true, when resetForm() is called the control displays correctly after resetForm().

[jasonaden]

Sounds like an issue that needs to be fixed. Can you please create a running example of your reproduction? We suggest using StackBlitz as you will get a full VSCode environment.

[kara]

This is actually working as expected. If you want to reset the form to a certain value, you must pass that value into the reset function.

this.user = new User();
this.form.resetForm(this.user);

[aec4444]

This isn't working as expected:

this.user = new User();
this.form.resetForm(this.user);

Is clearing the fields, but it isn't doing this:

1. Resetting the controls to the this.user.
2. Populating dropdowns to the value in transpiler: show line numbers that have errors #1 above
3. Removing ng-submitted from the form.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}