AngularJS: Migration from 1.2 to 1.4, part 2

In the first part we went over all the main problems of the transition to the new version, and in this we will touch on why we did it.

As mentioned earlier, the main reason for the transition can be a significant increase in the speed of the application: 4.3 times faster manipulations with DOM and 3.5 times faster $digest cycles (compared to 1.2), as Jeff Cross and Brian Ford stated at ngEurope conference .

However, this speed is for the most part acquired not through internal optimizations and magic, but by providing tools that allow you to write code more efficiently.

Let's look at these tools!

Debug info

It’s not news that Angulyar spends a significant amount of resources on information that facilitates debugging, such as adding classes.
DOM elements (for example, the ng-binding and ng-isolated-scope classes) or attaching various methods to access the scope (for example, .scope() and .isolateScope() ) to them.

All this is useful and necessary for the work of tools such as Protractor and Batarang, but is this data needed in production?

Starting from version 1.3 , debug info can be disabled:

 app.config(['$compileProvider', function ($compileProvider) { $compileProvider.debugInfoEnabled(false); }]); 

But what to do if we need to launch production, and debug is disabled?

Here, the .reloadWithDebugInfo() method of the angular object will save us, and since the angular object is global, we can execute this code simply from the console:

 angular.reloadWithDebugInfo(); 

$ applyAsync

With version 1.3 , the $applyAsync service came, in many respects similar in its mechanics to the already existing $evalAsync service:

Simply put, it adds an expression to the queue, then it waits (setsTimeout (..., 0), in modern browsers it is about 10 milliseconds), and if no other expression is added to the queue in the past time, it starts
$rootScope.$digest() .

This allows you to run multiple parallel expressions that affect the DOM, being sure that they will run in the same $ digest cycle and not worrying about the frequent use of $ apply.

What is the difference from $ evalAsync?

The main difference is that $applyAsync itself executes the entire expression queue at the beginning of the $digest loop, before dirty checking, which allows it to be executed only once, while the $evalAsync runs during a dirty check (more precisely, in the the beginning of the dirty check loop), and any expression added to the queue (outside $ watch) will start the $ digest loop again, which will lead to the repeated execution of the expression in the same $digest bit later.

[more]

However, the true benefits of using this tool can be seen in the internal services of the angular, for example, in $httpProvider .

$ http

The main difference between the $http service and other ways to make an XHR request is the $apply call when it is completed.

The problem lies in the set of parallel queries, each of which causes $apply at its completion, which leads to brakes.

The problem is solved with the arrival of $applyAsync in version 1.3 :

 app.config(function ($httpProvider) { $httpProvider.useApplyAsync(true); }); 

This code includes the use of the $applyAsync inside $httpProvider .

This allows you to run $ apply only once, when all promises of simultaneous queries will be resolved , which gives a significant performance boost.

Bind once

One of the main performance problems in AngularJS is the huge amount of $watch 's due to the fact that two-way binding is applied to all expressions, but not all data require it.

For static data, one-way binding is sufficient, without hanging yesterday, and before this was solved by custom directives, but everything changed in version 1.3 .

Starting with version 1.3 , a new syntax is available in the form :: at the beginning of an expression.

Any expression starting with :: will be perceived as one-way binding and will no longer be monitored (unwatch) as soon as the data in the expression becomes stable and passes the first $digest cycle.

For example:

 {{:: foo }} <button ng-bind=":: foo"></button> <ul> <li ng-repeat=":: foo in bar"></li> </ul> <custom-directive two-way-bind-property=":: foo"><custom-directive> 

Data stability:

Data is considered unstable as long as it is undefined . Any other data, be it NaN , false , '' , [] or null , is considered stable and will result in unwatch expressions.

This is necessary for static data that is not available during the first $ digest cycle.

For example, if the data comes from the server, you can simply keep the variable value undefined while waiting for a request. All this time, the pattern of this expression will live and only after setting data other than undefined , will it give ends.

Treat expressions with :: as a constant: once it is set, it is no longer possible to change it.

Update non-updateable:

Suppose we have an expression that is not updated in 99 cases out of 100 (that is, we didn’t fall for it), but sometimes it is required. How to be? I wondered if the bind-once expression could be updated by force.

No, you can't :) However, you can write your own attribute directive, which will force the entire directive to be re-compiled in response to certain events. An example is available here .

This part of the performance ends, and you can talk about just nice buns:

ngModel Options

Version 1.3 presented in addition to the ng-model auxiliary directive ng-model-options , which is responsible for when the model is updated.

The update time depends on two factors:

1) updateOn - special events (events) for which the model is updated, for example, it can be blur , click or some kind of custom event. The default is always default , meaning that each control will use its own event. If you want to extend the standard event by adding your {event: "default customEvent"} , do not forget to add to the default list, for example: {event: "default customEvent"} .

2) debounce - delay in updating the model in anticipation of new data (default 0, i.e. instantly). If you specify the {debounce: 300} input and enter 3 characters with an interval of less than 300 milliseconds, your model (and therefore various modifiers / validators) will be updated only once. In addition, debounce can be combined with events by specifying a delay for each of them, for example: {event: "default customEvent", debounce: {default: 0, customEvent: 400}} .

This allows us to get rid of many bicycles (farewell, setTimeout / clearTimeout) and significantly improves performance (after all, we get rid of the useless restart of $digest , and accordingly all $watchers ), and also reduces the number of false positives for asynchronous validation (however, $http the service is smart enough not to send spam with queries, but wait for stable data).

But there are three more useful options.

The allowInvalid flag allows you to set $modelValue , even if the value is not valid for it (by default, while the value is not valid, the model is written undefined , which does not allow, for example, to know the intermediate value)

The setterGetter flag allows you to set your own function as ngModel , a kind of intermediary between ngModel.modelValue and ngModel.viewValue acting as a setter and getter. A live example on plunker .

timezone allows you to set the time zone for time related controls ( date or time ), for example, '+0430' will mean '4 hours 30 minutes GTM'. By default, the browser time zone is taken.

Ignoring updateOn and debounce

Sometimes when manually recording a model, you need to ignore the delay set in the events and perform the update instantly. For this there is a method ngModelCtrl.$commitViewValue() .

Undo change

If it is necessary to undo all changes and hangs in the debounce process, there is a $rollbackViewValue() method (formerly $cancelUpdate() ), which customizes the view to the current state of the model.

As an example of using this feature, official documentation suggests inpat, changes in which can be rolled back by pressing ESC.

Detailed documentation

Validation

One of the major improvements in terms of usability is the validation of forms.

Previously, we had to implement the validation mechanism through ndModel.$formatters and ndModel.$parsers , affecting the validation result directly, through ndModel.$setValidity() , and the implementation of asynchronous checks delivered a separate joy.

Innovation affected the performance:

After all, the previously validating functions were launched with each update in the DOM ( $parsers ) or model ( $formatters ), often affecting each other’s values, thereby restarting the test loop again.

In the new version, validation is launched only if the model is changed and only if there is no error in this model ( {parse: true ). The influence on the model or the representation of the control inside the validator is also excluded, which has a positive effect on the speed of the application.

Synchronous

For synchronous validation, the new version offers us the ndModel.$validators , expanding it with a validator function.

The validator function must return true or false for valid and non-valid values, respectively.

Example:

  ngModel.$validators.integer = function(modelValue, viewValue) { // ,      if (ctrl.$isEmpty(modelValue)) { return true; } if (INTEGER_REGEXP.test(viewValue)) { return true; //   } return false; //    }; 

Asynchronous

For asynchronous validation, the ngModelCtrl.$asyncValidators collection is used, with the same logic expanding it with a validator function.

The main differences of the asynchronous version:

• Asynchronous validation starts only if all synchronous validations are valid.
• The validator function should return only promis, implementing its resolve() or reject() , for valid and non-valid values, respectively.

Promises in AngularJS are generated by a special $q service, as well as services like $timeout and $http , which basically also use $q .

The collection contains no more than one promise returned by one validator. This means that if validation is called several times, only the promise from the last call of the validator will be counted, regardless of the result of the previous promises.

From the moment a promise is transmitted by the validator function, and until resolved ( resolve() or reject() ), the ngModelCtrl.$pending field stores the name of the validator, and ngModelCtrl.$valid ngModelCtrl.$invalid and ngModelCtrl.$invalid are equal to undefined

Be careful with this feature: as long as validation is in FormCtrl.$errors form will not be valid, and you will not see any errors in FormCtrl.$errors Errors, but you can see "waiting" validators in FormCtrl.$pending .

  ngModelCtrl.$asyncValidators.username = function(modelValue, viewValue) { // ,      if (ctrl.$isEmpty(modelValue)) { return $q.when(); } var def = $q.defer(); //    $timeout(function() { if (usernames.indexOf(modelValue) === -1) { def.resolve(); //  ,   } else { def.reject(); //  ,    } }, 2000); return def.promise; }; ngModelCtrl.$asyncValidators.uniqueUsername = function(modelValue, viewValue) { var value = modelValue || viewValue; // ,     return $http.get('/api/users/' + value). then(function resolved() { //  ,   ,     return $q.reject('exists'); }, function rejected() { //   ,  ,    return true; }); }; 

It is worth using asynchronous validation with fields that use value modifiers (via $formatters and $parsers ): this can cause multiple operations, as well as false validation or invalidation of the field.

 var pendingPromise; ngModelCtrl.$asyncValidators.checkPhoneUnique = function (modelValue) { if (pendingPromise) { return pendingPromise; } var deferred = $q.defer(); if (modelValue) { pendingPromise = deferred.promise; $http.post('/', {value: modelValue}) .success(function (response) { if (response.Result === '   ') { deferred.resolve(); } else { deferred.reject(); } }).error(function () { deferred.reject(); }).finally(function () { pendingPromise = null; }); } else { deferred.resolve(); } return deferred.promise; }; 

ngMessages

Module ngMessages designed to facilitate the display of messages on the page.

Despite the fact that this module can be conveniently used for any messages on the page, it is usually used to display errors in the forms. To understand what problems this tool solves, let's see what pain the old way of displaying errors gave us, and compare it with the new one.

For the comparison example, we will use this form for adding a comment:

 <form name="commentForm"> <ul class="warnings" ng-if="commentForm.$error && commentForm.$dirty"> ... </ul> <label>:</label> <input type="text" name="username" ng-model="comment.username" required> <label>:</label> <textarea name="message" ng-model="comment.message" minlength="5" maxlength="500"></textarea> </form> 

Let's leave the implementation directly validation and consider only the display of messages about the necessary conditions:

• The field "Name" must not be empty
• The field "Message" must not be less than 5 characters
• The field "Message" must not exceed 500 characters
  The errors will be displayed in the .errors block.

Old methods of displaying errors

 <form name="commentForm"> <ul class="warnings" ng-if="commentForm.$error && commentForm.$dirty"> <span ng-if="commentForm.message.$error.minlength">      5  </span> <span ng-if="commentForm.username.$error.maxlength">      500  </span> <span ng-if="commentForm.username.$error.required">    </span> </ul> <label>:</label> ... <label>:</label> ... </form> 

 <form name="commentForm"> <ul class="warnings" ng-if="commentForm.$error && commentForm.$dirty"> <span ng-if="commentForm.message.$error.minlength && commentForm.username.$valid">      5  </span> ... </ul> <label>:</label> ... <label>:</label> ... </form> 

New methods of displaying errors

 <script src="path/to/angular-messages.js"></script> 

 angular.module('myApp', ['ngMessages']); 

Basic work with this module comes down to working with two directives:

1. ng-messages - the container containing our messages
2. ng-message - direct message

ng-messages takes as an argument a collection, the keys of which will check and show already ng-message , which take as an argument for comparison a string or expression (starting with 1.4 ).

Let's repeat the example of the same form for adding a comment, but using ngMessages :

 <div ng-messages="commentForm.message.$error" class="warnings"> <p ng-message="minlength">      5  </p> <p ng-message="maxlength">      500  </p> <p ng-message="required">    </p> </div> 

ngMessages can ngMessages be used as an element:

 <ng-messages for="commentForm.message.$error" class="warnings"> <ng-message when="minlength">      5  </ng> <ng-message when="maxlength">      500  </ng> <ng-message when="required">    </ng> </ng-messages> 

And so, right ngMessages solved two problems for us:

• The noodles of the conditions turned into a readable switch like list.
• The problem with the output of messages one by one decided by itself

In addition, the problem of prioritizing the output of messages is also being solved. Everything is simple here: messages are displayed according to their location in the DOM.

Multiple messages can be enabled by adding the ng-messages-multiple attribute to the ng-messages-multiple directive:

 <ng-messages ng-messages-multiple for="commentForm.message.$error"> ... </ng-messages> 

– ngMessages , , , :

 <ng-messages ng-messages-include="length-message" for="commentForm.message.$error"> </ng-messages> 

 <ng-messages for="commentForm.message.$error"> <ng-messages-include="length-message"></ng-messages-include> </ng-messages> 

(, ) , :

 <script type="script/ng-template" id="length-message"> <ng-message when="minlength">     </ng-message> </script> ... <ng-messages for="commentForm.message.$error"> <ng-messages-include="length-message"></ng-messages-include> </ng-messages> <ng-messages for="anotherForm.someField.$error"> <ng-messages-include="length-message"></ng-messages-include> </ng-messages> 

, , . .

, 1.4 , ng-message-exp :

 // error = {type: required, message: '    '}; <ng-messages for="commentForm.message.$error"> <ng-message-exp="error.type"> {{ error.message }} </ng-message-exp> </ng-messages> 

ng-message-exp , ng-message , ( expression ). , , , AJAX .

– . ng-messages !

:

• ng-messages

bindToController

[]

, controller as , scope .

, this.something . .

For example:

 app.directive('someDirective', function () { return { scope: { name: '=' }, controller: function () { this.name = 'Foo' }, controllerAs: 'ctrl' ... }; }); 

name .

:

  $scope.$watch('name', function (newValue) { this.name = newValue; }.bind(this)); 

, , , , ?

1.3 :

bindToController .

 app.directive('someDirective', function () { return { scope: { name: '=' }, controller: function () { this.name = 'Foo' }, bindToController: true, ... }; }); 

ctrl.name $scope.name .

1.4 :

 app.directive('someDirective', function () { return { scope: true, bindToController: { name: '=' }, controller: function () { this.name = 'Foo' }, ... }; }); 

scope bindToController .

, bindToController , , , scope , scope .

- scope , true . bindToController scope .

 {{ expression | filter }} 

, , «» ( expression ), ( filter ). , , , .

1.3 : , . , , $digest , , . , , .

plunker

: , , - ? , , «» , ?

1.3 ( stateless ) ( stateful ) . stateless . , $stateful true .

Example:

 angular.module('myApp', []) .filter('customFilter', ['someService', function (someService) { function customFilter(input) { //     someService input += someService.getData(); return input; } customFilter.$stateful = true; return customFilter; }]); 

Breaking change:
, . , , .

dateFilter

weeks

Conclusion

That's all. - , .

, .