AbstractControl.markAs* asymmetry is confusing, limiting

[xealot]

I'm submitting a ... (check one with "x")

[x] bug report
[x] feature request

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 implement reset() and the other markAs functions that handle their children.

• Angular version: 2.0.0
• Browser: all
• Language: all

[xealot]

Alternatively to this, having a way to manually kick off validation would solve my particular use case.

[pkozlowski-opensource]

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.

I'm not sure this parallel holds... dirty means that a user interacted with a given control. So if we take a parent<->child relationship into consideration - if a form is dirty it means that a user interacted with a form. But it doesn't meant that she interacted with each and every control of a form.

The same reasoning which was originally used to implement reset() and the other markAs functions that handle their children.

This is different. With reset you are saying - get me the form to the initial state. This implies resetting children as well.

I don't think we can consider dirty and reset as a similar use-case and I don't think that those methods should behave the same. What would be interesting is to better understand your use-case as I'm not quite clear about:

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.

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 newRecord / update flag in your component and base validation errors display based on this.

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?

[xealot]

Sure thing, let's ignore my particular use case for one moment and simply discuss the concept of marking children as dirty.

FormGroup and FormArray are not controls that the user interacts with directly, they are collections of controls that the user interacts with. The statuses they surface are a reduction of their children, as the documentation says. With this in mind, if FormGroup provides a markAsDirty() function, does it make sense that the FormGroup can be dirty and yet all of its children can be clean?

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:

• Adding a flag for error display component that optionally shows/hide errors regardless of control state
• Using CSS adjacency selectors and flags to hide/show validation (.ng-invalid ~ .errors) and relying on a parent selector to make that behavior optional
• Iterating through controls and marking as dirty to force validation to show, even though the controls have no been touched

As an example from a separate domain, on the server-side, most HTML form libraries will not show validation errors unless a validate() method has been called. This indicates that you want to see what issues are present.

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.

[pkozlowski-opensource]

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?

[xealot]

I would like to understand this better: how / when you show error messages us totally up to you, right?

Anything can be implemented with enough effort. :)

I mean, you can choose whatever combination of flags / control state to achieve desired result. You can totally show errors only on submit.

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:
http://plnkr.co/edit/po7NGV

[kara]

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 markAllDirtyand markAllTouched methods if this proves to be a pain point.

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.

[MarcinMilewski]

Procedure to mark all form control tree dirty:

static markAllDirty(control: AbstractControl) {
      if(control.hasOwnProperty('controls')) {
          control.markAsDirty(true) // mark group
          let ctrl = <any>control;
          for (let inner in ctrl.controls) {
              this.markAllDirty(ctrl.controls[inner] as AbstractControl);
          }
      }
      else {
          (<FormControl>(control)).markAsDirty(true);
      }
  }

[itsdevdom]

While @MarcinMilewski's solution works perfectly, a markAllAsDirty method in Angular Forms itself would be much nicer indeed.

[touqeershafi]

Yeah that will be good if it can be available for next release ?

[dan-lennox]

Recursive version for when there are a few levels of nested controls.

public static markAsDirtyDeep(control: AbstractControl): void {

  // Mark this control as dirty.
  control.markAsDirty();

  // Recursively mark any children as dirty.
  if (control.hasOwnProperty('controls')) {
    _.each((<any>control).controls, (childControl) => {
      this.markAsDirtyDeep(childControl);
    });
  }
}