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
AbstractControl.markAs* asymmetry is confusing, limiting #11774
Comments
Alternatively to this, having a way to manually kick off validation would solve my particular use case. |
I'm not sure this parallel holds...
This is different. With I don't think we can consider
Remember that what gets validated is user input so I'm not sure I understand why entry for a new record should be validated differently from an updated one. I mean - if a user enters invalid info into a field it is still invalid - new or update. In any case you could always have a All in all I don't think that the mentioned methods should be symetric but it is hard to me to propose an alternative since I don't grasp your use-case. Care to elaborate? |
Sure thing, let's ignore my particular use case for one moment and simply discuss the concept of marking children as dirty.
I assert, that while this seems a minor distinction, does not make as much sense as the opposite. Coming back around to my use case. I have a component that displays validation errors and typically it keys off of whether or not some interaction has happened on the screen. In some cases we want to show validation errors in the form from the start (load from db, collaboration) or trigger them all to show during some page event (submit without changes) simply to inform the user about what's wrong. It's confusing to have a record loaded with invalid controls and require the user to touch each one to see the errors. There are a few ways to solve this:
As an example from a separate domain, on the server-side, most HTML form libraries will not show validation errors unless a In summary, I suppose my real complaint is that showing or hiding validation is conflated somewhat with state of the control and it's not always sensible or easy to mutate that state. |
I would like to understand this better: how / when you show error messages us totally up to you, right? I mean, you can choose whatever combination of flags / control state to achieve desired result. You can totally show errors only on submit. I'm starting to get the impression that we start to mix control state + errors attached to it with when those errors are displayed. Maybe a minimal plunk with your distilled use-case would help make this discussion more concrete? |
Anything can be implemented with enough effort. :)
If I wanted to show all of the form errors when a user clicked a "Show Errors" button, can I do that without implementing a mechanism totally outside of form control state to achieve that? I think the decision to show validation is always derived from the state of the control. Whether it's valid certainly, and sometimes whether it's dirty/touched. Vastly simple example: |
It seems like there are two concerns at play here: how we are calculating dirtiness in markAsDirty (and etc) and controlling when/how validation runs. Regarding the first, agree with @pkozlowski-opensource. It's worth noting dirty and pristine state don't have the same contract with their children. If a group is dirty, it means at least one of its children is dirty. In contrast, a group is pristine only when all its children are pristine. So when you reset a group, all children must be marked pristine to maintain the model. The same is true with "untouched". It's less clear with dirtiness because only one needs to be marked dirty to satisfy the model. Marking just one would be arbitrary and marking the group dirty doesn't necessarily mean that you want every single child dirty. Because of the ambiguity, this method is conservative and does not mark the children at all. Inclined to leave it as is because I don't think changing this behavior would have sufficient benefits to justify breaking people. That said, we might consider adding additional The second concern about manual validation is a valid one. I think we can do better. But it appears to be a duplicate of #6170, so let's continue the discussion there. |
Procedure to mark all form control tree dirty:
|
While @MarcinMilewski's solution works perfectly, a |
Yeah that will be good if it can be available for next release ? |
Recursive version for when there are a few levels of nested controls.
|
In case anyone reading this, that's my solution:
|
Leaving this here for people who have similar issues |
My component had an ngIf that prevented the ng-pristine class from being removed / applied when I called markAsDirty(). I ended up changing the ngIf to a class and then the css classes were properly applied to my input textbox. This is probably just a lifecycle issue for me as the ngIf condition was probably not true when I called markAsDirty, but the css approach works in my situation. Control Template where ng-pristine is not removed <div *ngIf="!isEditMode">
{{value}}
</div>
<div *ngIf="isEditMode">
<input class="form-control" type="text" [(ngModel)]="value" [maxlength]="maxLength" [placeholder]="placeHolder" (blur)="onBlur()">
</div> CSS approach so markAsDirty removes ng-pristine from my input element. <div *ngIf="!isEditMode">
{{value}}
</div>
<div [class.hide]="!isEditMode">
<input class="form-control" type="text" [(ngModel)]="value" [maxlength]="maxLength" [placeholder]="placeHolder" (blur)="onBlur()">
</div> |
Thanks much appreciate! |
Doesn't work with FormArray |
For those worried about performance, this solution doesn't use recursion, although it still iterates over all controls in all levels. @ivancas84 This works also witth FormArray. (See it working here)
Original Stack Overflow thread. |
@ivancas84 https://github.com/Ismaestro/ngx-scroll-to-first-invalid This one is working |
For me works changing markAsTouched() instead of markAsDirty |
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
There are
markAs
methods that can manipulate a form's internal validation state. These are highly useful. However, they propagate to children only sometimes.The following methods also mark their children:
markAsUnTouched
markAsPristine
These methods do not mark their children:
markAsTouched
markAsDirty
I'm not even sure what this method is for...
markAsPending
Expected behavior
All methods to mark validation should interact with their groups either always or optionally.
Alternatively, some basic iteration machinery should be introduced so that we may instrument our own state changes easily.
What is the motivation / use case for changing the behavior?
For example; I want to show validation when loading a record from the DB but I would prefer not to show validation when creating a new record. It would be convenient to to mark everything as dirty or at least touched (as my validation would key off of those states) at the form level.
Conceptually, considering the semantic meaning of
FormGroup
, it seems if a parent control is marked as dirty that would indicate the children are dirty as well. The same reasoning which was originally used to implementreset()
and the othermarkAs
functions that handle their children.The text was updated successfully, but these errors were encountered: