Rosher Consulting

Software Consulting and Development Services

Angular Tips: Measuring Rendering Performance

Recently I’ve had to try and improve the performance of a page that had too many watches, specifically I had a table where each row was generated with an ‘ng-repeat’ and then within each row I had a ‘select’ element whose options were also generated with an ‘ng-repeat’. The ‘select’ had around 200 options with a binding for both the value and text, the number of rows varied but probably averaged around 5 and each row had a few bindings itself, so tally that up and you’re looking at over 2000 bindings, which when combined with the rest of the page was quite simply too much.

There are many ways of improving the performance of this page but before attempting any changes I wanted to be able to measure the rendering performance, so that I would then have something to compare my changes to.

I’d previously read the blog post from Scalyr on improving Angular rendering performance and in this post they mentioned that they ‘detected the finish of the $digest cycle’ in order to measure the rendering performance. I was curious how they did this and nothing obvious popped up in my searching, however I then noticed a question in the comments, which Scalyr responded to that pointed me in the right direction, I quote:

‘The approach we used was to use a $provider decorator on the $rootScope service to monkey patch $rootScope.$digest. In the override method, we simply record the start time, invoke the original $digest method, and then capture the end time.’

From this I was able to determine that I needed to override the regular ‘$digest’ method and replace it with my own, so I came up with the following simple override:

   1:  angular.module('myApp').run(['$rootScope', function($rootScope) {
   2:   
   3:              var $oldDigest = $rootScope.$digest;
   4:              var $newDigest = function() {
   5:                  console.time("$digest");
   6:                  $oldDigest.apply($rootScope);
   7:                  console.timeEnd("$digest");
   8:              };
   9:              $rootScope.$digest = $newDigest;
  10:          }])

This will call 'console.time' when the ‘$digest’ starts and 'console.timeEnd' when it finishes, which allowed me to see how long each render of the DOM takes. Combined with some logging in my controller I was then able to see that after my data had been loaded from the server it took around 3-4 seconds to render this to the page and for the page to be ready for input.

With some useful measurements to hand, I could now begin the process of making some improvements.

Angular Tips: Displaying an Ajax loading spinner using a custom Interceptor

I think one of the reasons Angular has become so popular, so quickly is because it has a series of conventions that make extending it really easy.

A common requirement for any UI is to let the user know when something is happening, such as when making ajax calls to the server and a common way to do this is to display a spinner. Prior to using AngularJS I would have handled this by creating my own module for talking to the server and then all other modules would have had to call this module, nothing wrong with this approach at all, but Angular already has its own module for dealing with ajax requests: ‘$http’, so we don’t really want to re-invent the wheel and create another module to sit on top of this.

This is where Angular’s extensibility comes in as we can handle this by hooking into Angular’s ‘$http’ service by creating our own interceptor, which allows us to intercept the request to the server, display the spinner, handle the response back and hide it again

Here’s a template for a custom interceptor that displays an ajax spinner when a request starts and hides it when the request finishes:

   1:  var App = angular.module('myApp', []).
   2:      config(['$httpProvider', function ($httpProvider) {
   3:          
   4:          $httpProvider.interceptors.push('myHttpInterceptor');
   5:          
   6:      }]).factory('myHttpInterceptor', ['$q', function ($q) {
   7:          var numRequests = 0;
   8:          var ajaxSpinner = $("#ajaxSpinner");
   9:          var hide = function (r) {
  10:              if (!--numRequests) {
  11:                  ajaxSpinner.hide();
  12:              }
  13:              return r;
  14:          };
  15:   
  16:          return {
  17:              'request': function(config) {
  18:                  numRequests++;
  19:                  ajaxSpinner.show();
  20:   
  21:                  return config;
  22:              },
  23:   
  24:              'response': function(response) {
  25:                  return hide(response);
  26:              },
  27:   
  28:              'responseError': function(response) {
  29:                  return $q.reject(hide(response));
  30:              }
  31:          };
  32:    }]);

This is pretty straightforward and adds a nice effect to our UI, but we can also take this a step further.

Whenever I want to send messages back from the server indicating success or failure I always send a standard object back, such as:

   1:  {
   2:      Error: true,
   3:      Message: 'An error occured saving XYZ'
   4:  }

Now I could handle this at the point I make the call, but since this is a standard message, this seems like a perfect fit for our custom interceptor.

The following code not only shows and hides our ajax spinner, it also checks the response and if necessary displays an alert to the user, saving us from having to handle this everywhere in our code:

   1:  var App = angular.module('myApp', []).
   2:      config(['$httpProvider', function ($httpProvider) {
   3:          
   4:          $httpProvider.interceptors.push('myHttpInterceptor');
   5:          
   6:      }]).factory('myHttpInterceptor', ['$q', function ($q) {
   7:          var numRequests = 0;
   8:          var ajaxSpinner = $("#ajaxSpinner");
   9:          var hide = function (r) {
  10:              if (!--numRequests) {
  11:                  ajaxSpinner.hide();
  12:              }
  13:              return r;
  14:          };
  15:   
  16:          return {
  17:              'request': function(config) {
  18:                  numRequests++;
  19:                  ajaxSpinner.show();
  20:   
  21:                  return config;
  22:              },
  23:   
  24:              'response': function(response) {
  25:                  if (response && response.data && response.data.Error && 
  26:                          response.data.Error === true && response.data.Message) {
  27:                      alert(response.data.Message);
  28:   
  29:                      return $q.reject(hide(response));
  30:                  }
  31:   
  32:                  if (response && response.data && response.data.Error === false && 
  33:                          response.data.Message) {
  34:                      alert(response.data.Message);
  35:                  }
  36:   
  37:                  return hide(response);
  38:              },
  39:   
  40:              'responseError': function(response) {
  41:                  if (!response)
  42:                      return $q.reject(hide(response));
  43:                      
  44:                  if (response.data && response.data.Error && 
  45:                          response.data.Error === true && response.data.Message) {
  46:                      alert(response.data.Message);
  47:                  } else {
  48:                      alert('Sorry, there was an error.');
  49:                  }
  50:                      
  51:                  return $q.reject(hide(response));
  52:              }
  53:          };
  54:    }]);

This is just a couple of examples of what we can do with a custom interceptor to help remove boilerplate from our code and hopefully it’s given you some ideas for your own code.

Angular Tips: Adding functionality to existing directives

One of the features I really like in Angular, which is not that well known is the ability to create new directives with the same name as existing ones and thereby add some new functionality to them.

When you register two directives with the same name, Angular doesn’t complain, it merely runs those directives in the order they were registered. A common scenario I use this for is to create my own ‘ng-click’ directive to provide some feedback to the user when they click a button, such as disabling it while waiting for an Ajax request to complete.

With the above scenario, if you were to look on Stack Overflow for questions about this, the most common answer would be to create your own directive, say ‘my-own-click’ and use that instead of the standard ‘ng-click’. The downside with this is that you have to re-implement the standard ‘ng-click’ functionality and you have to remember to use your ‘my-own-click’ directive everywhere. If you’re working in a team, this then means all of your co-workers also need to know to use this new directive.

A Better Approach

The following is the basic template I use in my projects to add some feedback to my buttons when an action occurs. The directive requires that you also attach an ‘ng-model’ to your button so that it can use the model variable to know when the action starts and ends:

   1:  angular.module('MyApp').directive('ngClick', function () {
   2:      return {
   3:          restrict: 'A',
   4:          link: function (scope, element, attrs) {
   5:              if (attrs.ngModel) {
   6:                  var el = element.find("span");
   7:                  var cls = el.attr("class");
   8:   
   9:                  scope.$watch(attrs.ngModel, function (newValue, oldValue) {
  10:                      if (newValue) {
  11:                          if (el.length) {
  12:                              el.attr("class", "glyphicon glyphicon-refresh fa-spin");
  13:                          }
  14:                          element.attr("disabled", true);
  15:                      } else {
  16:                          if (el.length) {
  17:                              el.attr("class", cls);
  18:                          }
  19:                          element.attr("disabled", false);
  20:                      }
  21:                  });
  22:              }
  23:          }
  24:      };
  25:  });

The directive itself does a bit more than just disable the button, it also looks to see if the button contains a child ‘span’ element and if it does, it assumes this is a Glyph Icon as used by Bootstrap and then changes the class of the ‘span’ to the Refresh icon and also uses the ‘fa-spin’ class from Font Awesome to rotate the icon, thereby actively showing the user that their action has caused something to happen.

Here’s the appropriate HTML to use this directive:

   1:  <button class="btn btn-primary" ng-click="save()" ng-model="saving">
   2:      <span class="glyphicon glyphicon-floppy-save"></span>
   3:      Save
   4:  </button>

And the ‘save’ function in your controller (this is calling a save method on a service which returns a promise, so we’re handling both the success and failure of the promise and updating the model variable appropriately):

   1:  $scope.save = function () {
   2:      $scope.saving = true;
   3:      myService.save($scope.data).then(function(result) {
   4:          $scope.saving = false;
   5:      }, function() {
   6:          $scope.saving = false;
   7:      });
   8:  };

As you can see, as long as you update the appropriate model variable in your controller, your button will automatically be updated without you having to remember to use the appropriate directive.

Obviously this isn’t totally free, in that you still need to do some work, but this could certainly be improved further by creating your own http interceptor for instance in combination with the custom ‘ng-click’ directive to identify which button was clicked and update appropriately.

Overall I love how easy Angular makes it to do things like this and your users will appreciate the feedback from your UI.