-
Notifications
You must be signed in to change notification settings - Fork 26.2k
RC6 Forms: Calling disabled() on FormControl makes entire form invalid #11379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
[copied from #11257] @capi The way the model works is that a parent form group is disabled if all its child controls are disabled. The status of group controls is always calculated as a reduction of the child controls. In your example, your form only has one form control. Once you disable it, you are effectively disabling the whole form because all its (one) children are disabled. If you log the status of the form, you'll see that its status is 'DISABLED', which is why valid is false. The statuses are mutually 8000 exclusive. Closing, as this works as designed. |
Thanks, that was a misconception of my part then. So a work-around for one-element forms is to add a dummy-control? |
@capi Could you tell me more about your use case? You have a one-control form that is disabled, but the status needs to be valid for some reason? |
@kara It's a special use-case. It's about interacting with a barcode scanner from inside an Android |
Thanks for the additional info. Am I understanding correctly that you'd like the field to be readonly if it is scanned in? Have you considered binding to the Alternatively, you could disable the control if it's explicitly invalid - Also worth noting that if you have only one control, you might consider switching to using |
@kara Just to make it clear. While using Thanks. |
@kara @marcalj We are experiencing the same behavior, and it looks quite troublesome to solve: on one hand, we could code the dynamic enable/disable behavior by subscribing to On the other hand, I was thinking about a custom directive to replace |
I've just stubbed this custom directive, which should behave as desidered. Warning: it's just a proof-of-concept, not a complete solution. Feedbacks are welcome, of course. @Directive({
selector: '[formControlName][dynamicDisable]'
})
export class DynamicDisable implements OnInit, OnChanges {
constructor(
@Optional() @Host() @SkipSelf() private parent: ControlContainer,
) {
}
@Input() formControlName: string;
@Input() dynamicDisable: boolean;
private ctrl: AbstractControl;
ngOnInit() {
if(this.parent && this.parent["form"]) {
this.ctrl = (<FormGroup>this.parent["form"]).get(this.formControlName);
}
}
ngOnChanges() {
if (!this.ctrl) return;
if (this.dynamicDisable) {
this.ctrl.disable();
}
else {
this.ctrl.enable();
}
}
} <form [formGroup]="form">
<label>
Make required
<input type="checkbox" formControlName="isRequired" [(ngModel)]="isRequired" />
</label>
<p>
<input type="text" formControlName="yourName" [(ngModel)]="yourName" [dynamicDisable]="!isRequired" />
</p>
<p>
Valid: {{form.valid}}
</p>
</form> @Component({
selector: 'home',
styleUrls: ['./home.css'],
templateUrl: './home.html'
})
export class Home {
form: FormGroup;
isRequired: boolean = true;
yourName: string = '';
ngOnInit() {
this.form = new FormGroup({
"isRequired": new FormControl(true),
"yourName": new FormControl('', [])
}); |
@unsafecode thanks, your directive is working well in my project and saved me some refactoring effort. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
I'm submitting a ... (check one with "x")
Current behavior
If I call
this.myForm.controls["code"].disable();
,this.myForm.valid
is alwaysfalse
:This outputs
Expected/desired behavior
The form should still be valid, even though the control has been disabled.
Reproduction of the problem
http://plnkr.co/edit/B8cA0zzcrt4SjxrGMlRf?p=preview
I initially remarked this as a comment in #11271, but I don't want to hijack the other issue, which is about dynamically binding
[disabled]
.It could be that PR #11257 fixes this already, but I am not sure, so I decided to file this bug-report.
The text was updated successfully, but these errors were encountered: