Support `emitEvent` option in FormGroup and FormArray APIs

[bitworking]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[x] 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

I have a dynamic (reactive) form and use methods like setControl and addControl. If I use these methods everytime a form valueChanges event is triggered which in my situation is very bad because I cannot differentiate it from a "real" form value change.

Expected behavior

I need to set the option "emitEvent: false" in the method calls for addControl and setControl.

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

I need to differentiate a value change from a form control change.

Environment

Angular version: 5.0.1

[Airblader]

I'm having the same issue in a form that is set up to auto-submit using valueChanges.debounceTime. It has a dynamic list of controls and using setControl to replace them triggers valueChanges, causing an infinite submission loop.

[Airblader]

By the way, my current workaround is to not subscribe to form.valueChanges$, but instead use my own Observable that I trigger from all the change handlers of the form controls. I only have (a list of) two dropdowns, so that's feasible. It'd still be better to tell setControl not to emit events.

[ottosson]

I'm listening to form changes and want to add a control when a specific condition in the form is met, which triggers a new change event in the form which is now an infinite recursion.

Should add/remove controls even trigger the changeEvent? Or should there be a different kind of event emitter for control value changes?

[Airblader]

I think the consistent behavior is what this issue is requesting, which is an option to suppress the events. That's how other parts of the API work as well.

[meriturva]

We are on same issue and emitEvent option is the only clean solution on our side!

[hatem20]

i have the same issue in angular 6 and can't find any workaround

[eramirezprotec]

Same issue here...

[NgxDev]

I cannot believe I banged my head against the wall for the last hour and didn't think about this from the start:

  this.frm.valueChanges
    .pipe(
      filter(_ => !this.pauseForm)
    )
    .subscribe(
      (v) => {
        // DO STUFF
      }
    );

Then, whenever I need to use setControl/addControl, I first do this.pauseForm = true; and after set/addControll I do this.pauseForm = false;
This looks a bit ugly, I'm sure... but I'm no RxJs expert, maybe some other operators can be leveraged to a prettier solution?

Hopefully, this issue will get some attention... it's been over 1 year 😄

[vuquangtam]

I cannot believe I banged my head against the wall for the last hour and didn't think about this from the start:

  this.frm.valueChanges
    .pipe(
      filter(_ => !this.pauseForm)
    )
    .subscribe(
      (v) => {
        // DO STUFF
      }
    );

Then, whenever I need to use setControl/addControl, I first do this.pauseForm = true; and after set/addControll I do this.pauseForm = false;
This looks a bit ugly, I'm sure... but I'm no RxJs expert, maybe some other operators can be leveraged to a prettier solution?

Hopefully, this issue will get some attention... it's been over 1 year 😄

Also use this workaround :D. Make my code look ugly 👎 but this is still the only way.