Recreating the form group prevents error message updates

[rickyhartmann]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x ] Bug report
[ ] Performance issue
[ ? ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Unsure if this would be a bug or feature request.

Current behavior

Replacing the formGroup with a new instance breaks the automatic rendering of validation messages.

Expected behavior

Ideally it would pick up on the new form control instance and continue operating normally.

Minimal reproduction of the problem with instructions

Clone of the demo app, with just a reset button added. Reset button simply replaces the initial FormGroup with a new one.

https://stackblitz.com/edit/netanel-control-er-j4ppfw?file=src%2Fapp%2Fapp.component.ts

I believe the issue lies in the NgControl injected into control-errors.directive. When the formgroup is recreated, the injected reference isn't updated to the new one. Short of destroying and re-rendering the entire form with a terribly hacky *ngIf, I haven't found a workaround. I feel like there has to be a better way to force the recognition of an update to an injected object?

[Netanel Basal]

Why recreating it, and not just update the values using patchValue?

[rickyhartmann]

Mainly due to the complexity of the objects I'm working with, and I suppose lack of foresight on my part. My data structure has quite a few levels to it, with nested arrays that can contain a variety of different types of objects. So I have factories and classes setup for everything that all have a toFormGroup() on them for both form initialization and data resets.

I updated the stackblitz with a quick and dirty sample of the pattern. https://stackblitz.com/edit/netanel-control-er-j4ppfw?file=src%2Fapp%2Fapp.component.ts

I do realize that could (and perhaps should) all be refactored to include a separate method utilizing patchValue, unfortunately I'm not sure I'll find the time to do that for a while. I also realize that's not your problem. :-) Which is why I wasn't sure if I should label this a bug or feature request. I understand if you feel this isn't a scenario worth addressing, but I figured it was at least worth asking the question.

[Netanel Basal]

The only thing I could suggest is to create a structural directive that'll make the code cleaner. For example:

<ng-template [errorTailorDynamic]="formGroup">
  <form [formGroup]=""formGroup>....</form>
</ng-template>

The directive will listen to input changes and re-render the view. I don't mind to include this as part of the library if you want to create a PR.

[Ralph Theart]

Hi @NetanelBasal just want to say your work is superb and was exactly what I was looking for. I'm facing a similar issue in that I'm trying to add/remove controls from formArray. I don't need to re-render the whole form as mentioned by Ricky. But when I hit save if there are any errors on the formGroup in the

the errors appear when I add another group dynamically.

Heres a stackblitz: https://stackblitz.com/edit/ionic-f6wek3?file=pages%2Fhome%2Fhome.html

Steps to reproduce error:

1. Just hit save to the required errors appear for Email Address1
2. Now try to [+ Add] a new email address

As you can see the errors also appear for the new pushed group.

Is this a bug or something I'm doing wrong ...I've even tried, after pushing to formArray, updateValueAndValidity() or setErrors() to null

Essentially how can I ensure that no error messages from errorTailor appear on generated control?

addNewInputField() in home.ts is where the items are being added. Thank you for your time and Happy New Year!

[Netanel Basal]

@greaterking I'll investigate when I find the time. In the meantime, if you can help and try to debug it, it'll be great.

[Netanel Basal]

@greaterking, I actually see the problem. It's because the form is already submitted; we both apply the form-submitted class and running the validation.

[Netanel Basal]

We can solve the first case by removing the shareReplay from the submit$ source, but you'll still stay with the form-submitted class, which will style your inputs as errored.

[Ralph Theart]

Thank you!… I was really trying to figure out what the issue was. Removing shareplay would be great… I can tackle form submitted class some another way.