SetErrors on formControl while hidden (by *ngIf) in template remove errors on control

[CharlBest]

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 => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

Step 1: (Optional) Type something into input (make it dirty + touched)
Step 2: Execute method on button click. In method:

• Hide formGroup in template.
• Make HTTP request.
• Set formControl error in HTTP request error callback.
• Show formGroup again in template.

Sorry it's difficult to explain. I think the StackBlitz example will clarify it more.

Expected behavior

The errors set on the form control should still be there (and not null) if the formGroup gets shown again in the template

Minimal reproduction of the problem with instructions

https://stackblitz.com/edit/angular-qyotxb

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

You expect the formGroup to hold onto the errors and not remove them.

Environment

Angular version: 6.0.7


Browser:
- [x] Chrome (desktop) version 67.0.3396.99 (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
 
For Tooling issues:
- Node version: v8.10.0  
- Platform:  Windows  

Others:

[robwormald]

*ngIf actually removes/destroys the associated DOM elements, so the associated controls are removed as well (otherwise things would get leaky) - you could use [hidden] (which visually hides the DOM elements but doesn't destroy them) to accomplish the same result as your demo, I think?

This is works as intended, but feel free to request a re-open if it doesn't solve the issue.

[CharlBest]

Hi @robwormald thanks for the reply. I understand that *ngIf removes the DOM elements and then re-adds them depending on the condition but according to this isn't suppose to effect the formGroup and the errors set on the controls. Take this example: https://stackblitz.com/edit/angular-qyotxb

When you do a fresh load and then click "Set Errors" (and that is all) you will see that in the template/DOM below the Errors heading it says null (no errors on control) but in the console you can see that the form status is "INVALID" and that the control does indeed have errors on it.

I can see why this is because I assume the errors gets set when the *ngIf gets set to true then form controls gets repopulated in DOM with fresh clean errors. but if you set the *ngIf to true first which means you construct the control in the dom first and then you set the errors shouldn't that work. In the example this means doing this.isProcessing = false first and then this.formGroup.get('name').setErrors(). I think it's because the change detection is running once or something. You probably know way more than me sorry if this is a stupid question.

[mlc-mlapis]

@CharlBest ... hmm, it has to be related to the fact that you are setting the error status inside in the error block of the subscribe.

If just simple async setTimeout is used as below, it works as expected.

setError() {
   setTimeout(() => {
      console.log('error');
      this.isProcessing = false;
      this.formGroup.get('name').setErrors({ required: true });
      console.log('Errors in res', this.formGroup.get('name').errors);
   }, 1000);
}

Both cases should have the same result but they haven't. I don't have any explanation in this moment for that. It looks like a bug.

[CharlBest]

Hi @mlc-mlapis Thank you so much for looking at this. I also had a suspicion that it maybe has something to do with weird async stuff. It does this in the error and success blocks so definitely something going on there. Thanks for the temp fix but I also think it's a bug. @robwormald from what @mlc-mlapis is saying do you still think this is the correct/intended behavior and maybe it makes a bit more sense what I was trying to explain. Sorry for the bad initial explanation and thanks for the look at this.

[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.}