ngForm: invalid while in pristine condition

[robschley]

I spoke with @IgorMinar and @matsko about this yesterday during ngConf. Matias asked me to create an issue.

In the current implementation of ngForm/ngFormController, a form is marked as invalid even before a user has interacted with it. I proposed that we add a feature to ngFormController that will allow developers to better control when validation is triggered so that the validation can be differed until after a user has interacted with a specific form control or attempted to submit the form.

I'm willing to help implement these changes if this is something that the team agrees is a good idea.

[caitp]

It doesn't sound unreasonable even as a default feature, why not?

[sparkalow]

+1

[MikeMcElroy]

So how did you envision this would look to the developer? A new directive that enhanced the pristine/valid functionality? Something like:

<form ng-valid-on-pristine>

or the like?

[matsko]

@robschley the content below doesn't solve your issue. I'll reply again with a solution to that.

@MikeMcElroy here's what I suggest we do to fix that. I think it would be better to have a validate() function on the form (in JS) and then once you've called that once then the form becomes reactive (this means errors are visible and update instantly).

<form name="myForm" ng-controller="FormCtrl" ng-submit="submit()">...</form>

myModule.controller('FormCtrl', function($scope) {
  $scope.submit = function() {
    $scope.myForm.validate(); //all validations are now "visible" and will stay reactive
  };
});

That way if you want the form to be reactive right away, just call validate() at the start of your form. What do you think?

[MikeMcElroy]

@matsko That sounds reasonable for the implementation side. It would also allow people to create directives to hook into specific fields to trigger validation immediately on dirtying, e.g.

<form no-validate-until_ready>
  <input name="this_doesnt_invalidate_on_dirtying" />
  <input name="this_validates_on_dirtying" validate-on-dirty />
</form>

How would this mode work for reset forms and ones which have been set to pristine programmatically? .validate() probably can't be a once-and-forever-afterwards thing, it might need some specification for .setPristine() usage.

Thought about this a few times as well. I do like how the ng-* classes on form controls always reflect the validity, even if you aren't communicating them to the user yet. Usually I end up with a showValidity property in a scope, and <form ng-class="{'show-validity': showValidity}">, which (if I don't want to show the validity while typing) is set to true once the form is submitted. CSS is then written like so: .show-validity .ng-invalid { border-color: red; }. (And validation-related messages in an ng-if that checks the validity and showValidity.)

[hrajchert]

+1

I think the solution could be in the lines of adding a method to ngModelController or ngFormController (not sure where it applies) to disable automatic validation.

<form> <!-- nothing gets added, default behaviour applies -->
   <input required> <!-- default behaviour -->
  <inpurt required ng-validate-on-dirty> <!-- disables automatic, validates manualy on dirty -->
</form>

<form ng-validate-on-dirty> <!-- changes default on all subelements-->
   <input required> <!-- only when dirty -->
  <inpurt required ng-automatic-validate> <!-- reenables automatic-->
</form>

What do you think?

[LeonardoBraga]

Just extending on @matsko's suggestion, I would name the method $validate, to follow ngModel's method with the same name and purpose.

Also, we have ngModelOptions directive that allows the customization of when a model change happens, through the use of updateOn. I would leverage a similar approach in a directive ngFormOptions, that would provide a property validateOn, with the possible values:

• default: current behaviour, form starts invalid
• dirty: validates when any model within the form becomes dirty
• touched: validates when any model within the form is touched
• dirty and touched can be combined

This way we provide an API that follows existing conventions, still having both declarative and imperative options, without introducing breaking changes.