Working with Validators and Messages in AngularJS

Reference from: http://odetocode.com/blogs/scott/archive/2014/10/16/working-with-validators-and-messages-in-angularjs.aspx

Here are a few points about form validation:

  1. When you give a <form> a name, Angular will add a property with the same name to the current $scope.
  2. All named inputs inside a named <form> will be added to the form’s named property in $scope.
  3. Each form and input still have boolean properties to describe if the object is $pristine or $dirty, and $valid or $invalid.
  4. Angular still adds CSS classes to each form and input describing the state of the object (ng-dirty, ng-pristine, ng-valid, ng-invalid).
  5. There is still an $error property on each form and input. The $error property describes failed validations.

Thanks to the behavior described in the above points, you can have a relatively functional form just using the following markup:

… and a litte bit of CSS..

You can try the above code on Plunker.

The Emperor’s  New Validations

emporerAngular 1.3 introduces a number of new features for form validation, including a new approach to writing validation code, a new approach to showing validation error messages, and plenty of small enhancements. like adding ng-submitted as a class to a form after a submit event. To only show validation errors or color code erroneous inputs after the user presses the submit button now only requires a more specific selector in CSS.

Try the updated plunk here.

What follows is some more detail about validation messages and the validation API.

ngMessages

One of the messier parts of forms with Angular was the display management of validation errors. The management usually involved ng-if or ng-show directives with ugly expressions like in the following code.

And this is only a single validation error for a single field. Once you added messages for each validation attribute in each input field, then added class names, there was quite a bit of markup.

ngMessages is a new module for Angular that your application can depend on after adding angular-message.js. Once in place, validation messages look like the following.

The ngMessages directive will watch the $error property of an input and toggle the first matching ngMessage directive in its messages collection.

Now we’ve gotten most of the uglier expressions out of the markup, but we can also define a template file for messages..

… and include the template whenever we need to show error messages for a field.

Now we’ve removed most of the unsightly and bulky markup from our forms. However, since error messages come from a template they are likely to be generic error messages like the ones in this example, messages like “Too small!”. There is no easy way to poke a field name or attribute value into a message, unfortunately, but there is the ability to override a message.

This last bit of code added to the Plunker here.

$validators

Also new in 1.3 is the $validators object on the ngModel controller. Adding a property to this object effectively registers a new validation rule to an input using the name of the property. To get to the $validators property you’ll want to create a custom directive that requires the ngModel controller. The following code adds an “odd” validation rule that I can use to ensure that an input type=”number” will only accept odd numbers.

Angular automatically invokes the odd function whenever the model value changes (you can also receive the view value as a second parameter)., All the validation function needs to do is return true or false – is the value valid? A return of false will mark the model as invalid and set a property on the associated $error object. To apply the validation rule use the directive on an element using ngModel.

The associated ngMessage for the attribute will automatically appear when the validation rule fails.

An updated plunk using the above code lives here.

$asyncValidators

A validation rule added to a model’s $asyncValidator pipeline will typically be a validation rule that needs server-side logic to make a decision. Like everything and anything async in Angular, an async validator will return a promise. If the promise resolves, Angular considers the value valid. If the promise is rejected, the value is invalid.

Here is a prime number validation rule that simulates a slow server-side response using $timeout.

Using an async validator is no more difficult than using a regular validator, all we need to do is add the directive to the input element.

Notice you can give some visual clues a pending validation calculation by using the $pending flag provided by Angular.

Try this version of the code in this plunk.

197 total views, 3 views today

Trả lời