Table of Contents
A couple months ago the Angular team announced that the former version of AngularJS (though mantained so far up to v 1.7.x) has been moved to Long Term Support (LTS) mode on July 1st 2018. This basically means that the first installment of AngularJS, although still being used by many developers worldwide, will gradually disappear from the web. For this very reason this will most likely be the last post we'll publish about AngularJS.
Despite its rather short lifespan, AngularJS has been a great framework for many web developers, and has unquestionably played a determining role for today's frameworks - the brand-new Angular, React and VueJS avove everything else. At the same time, the framework's built-in features of AngularJS were affected by some serious performance problems that could be crippling when creating a bigger application. Most of the old AngularJS 1.x developers are still unaware of some of these important facts, which - when properly addressed - can positively affect their app performance.
Below are some essential points which you keep in your mind while creating an app using the former version of AngularJS. If you've switched to the new Angular rebuild (from 2.x to the latest Angular 6), ignore this post and read these new Angular tutorials instead.
Try to use binding once
The one-time binding syntax ought to dependably be utilized for this situation, which is {{::value}}. This syntax renders the data once and gives it a chance to continue as before without the data being influenced by any model updates that will come later on. The most recent version of AngularJS has acquainted a twofold colon documentation with implying this syntax.
The single binding syntax is here to make things quick and in particular simpler. It is a syntax that will be anything but difficult to use by any web engineer and will help in bringing down the $$watcher. At last, AngularJS will have less work to do, bringing about the applications to be more responsive.
Don't use repeated filters
Avoid using repeated filters can definitely accelerate the responsiveness of your application. To quickly put it into code, instead of writing this
|
1 |
{{'DESCRIPTION' | translate }} |
You can do this:
In AngularJS:
|
1 |
$scope.description: $translate.instant('DESCRIPTION') |
In HTML:
|
1 |
{{::description}} |
Likewise, endeavor to cache data at whatever point conceivable.
Avoid too many Watchers
On the off chance that conceivable dodge them absolutely, however in the event that not utilize them on a negligible level. At whatever point your application is backing off, it is mostly in light of the fact that you are utilizing a larger number of watchers than you ought to or in light of the fact that the watchers you are utilizing are working more than they should. At the point when filthy checking is being utilized keeping in mind the end goal to find every one of the progressions that have been made, the cycle does not end as quickly as it should when there are such a large number of watchers being used.
This is the thing that backs off everything. The issue is that it is anything but difficult to include numerous watchers in AngularJS, so be mindful so as to keep away from them however much as could reasonably be expected.
Avoid ng-rehash
With regards to AngularJS performance, ng-rehash turns into the principal guilty party. It, for the most part, manages varieties of $scope Objects and this influences the performance of the $digest cycle. It is in this way vital to stay away from it is conceivable, however, in the event that you should utilize ng-rehash, you can utilize pagination or infinite scrolling as they don't influence performance as much as ng-rehash.
On the off chance that you utilize infinite scrolling, make sure to utilize track by, such as the following example:
|
1 2 3 4 5 |
<ul class="tasks"> <li ng-repeat="task in tasks" ng-class="{done: task.done}"> {{task.id}}: {{task.title}} </li> </ul> |
Using DOM filters wisely
When utilizing filters, you will understand that they are anything but difficult to utilize, which will provoke you to utilize them considerably more. There is nothing incorrect in utilizing them, however, just that AngularJS will run the filters twice in each $digest cycle each time you change something. If you use too many of them, you'll eventually have a performance decrease in your app.
Here's an example of a rather slow filter that you should positively avoid:
|
1 |
{{filter_expression | channel : expression : comparator}} |
As a general advice, if you can stay away from the inline channel syntax, data will be handled better and faster by the rendering engine.
Constraining the filters is simple, and it will greatly benefit your app performance.
Use $watchCollection instead of $watch
$watch with just two parameters will work considerably quicker. The issue is that it isn't bolstered by AngularJS. The one that AngularJS bolsters is unified with the third parameter, however, the framework will be constrained to direct a profound checking for each property of the protest, which winds up moderating things. That's why Angular included $watchCollection:
|
1 |
$watchCollection('value', function(){}) |
As a matter of fact, $watchCollection performs much like the $watch with a third parameter just that the previous one works substantially quicker in light of the fact that it just checks the main layer of the properties of the question.
Benchmark your code
console.time is an outstanding JS command that many web developers can use to benchmark their code. It works extremely well at whatever point you are debugging performance issues in Angular. It can be used in the following way:
|
1 2 3 |
console.time("TimerName"); // some code console.timeEnd("TimerName"); |
This is a quick and neat way to measure the code execution time without using third party packages.
