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) {
   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) {
   4:          $httpProvider.interceptors.push('myHttpInterceptor');
   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:          };
  16:          return {
  17:              'request': function(config) {
  18:                  numRequests++;
  19:        ;
  21:                  return config;
  22:              },
  24:              'response': function(response) {
  25:                  return hide(response);
  26:              },
  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) {
   4:          $httpProvider.interceptors.push('myHttpInterceptor');
   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:          };
  16:          return {
  17:              'request': function(config) {
  18:                  numRequests++;
  19:        ;
  21:                  return config;
  22:              },
  24:              'response': function(response) {
  25:                  if (response && && && 
  26:                 === true && {
  27:                      alert(;
  29:                      return $q.reject(hide(response));
  30:                  }
  32:                  if (response && && === false && 
  33:                 {
  34:                      alert(;
  35:                  }
  37:                  return hide(response);
  38:              },
  40:              'responseError': function(response) {
  41:                  if (!response)
  42:                      return $q.reject(hide(response));
  44:                  if ( && && 
  45:                 === true && {
  46:                      alert(;
  47:                  } else {
  48:                      alert('Sorry, there was an error.');
  49:                  }
  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");
   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:  $ = function () {
   2:      $scope.saving = true;
   3:$ {
   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.

Unit Testing AngularJS with Jasmine, Chutzpah and Visual Studio

Recently I’ve been working on a project that heavily utilised AngularJS for its client side functionality. Since all of my server side C# code was all unit tested I wanted to add some unit tests to my Angular controllers and services. Unit testing C# and server side code is well understood, with plenty of tools available and support baked in to Visual Studio, but the idea of unit testing JavaScript is reasonably new, which means that the number of tools available to a developer (especially a .NET/C# dev) is quite limited and the IDE support minimal.

Fortunately the community has been very active in this area, so everything was available for me to get unit tests added to my project, I just needed to work out how to do it.

Since I’m working with Angular, the first thing I did was look at the code samples on the Angular site, which all come with unit tests, these use the Jasmine testing framework and I came across a couple of good articles on testing Angular controllers and services using Jasmine here and here – Note that I won’t be providing example unit tests with this blog post, the examples on the Angular site and the preceding two links cover it far better than I ever could.

This all seemed straightforward so far, however I wanted to get this nicely integrated into Visual Studio, so a bit more Googling and I came across Chutzpah (pronounced hutz-pah). Chutzpah is an open source test runner which lets you integrate JavaScript unit tests into Visual Studio and enables you to run them from the command line, which means you can integrate your tests into your build process.

Installing Chutzpah

Chutzpah can be installed from NuGet, just right-click on your project or solution in Visual Studio and choose ‘Manage NuGet' packages’, then search for ‘Chutzpah’, it should be the first result found:


To run Chutzpah from within Visual Studio you will also need to install two plugins, the first is ‘Chutzpah.VS2012.vsix’, this integrates into the unit test explorer window in Visual Studio, the second ‘chutzpah.visualstudio.vsix’ integrates into Visual Studio’s context menu so you can right-click on a test and run it.


If you’ve got Resharper installed then it automatically supports running Jasmine unit tests so you won’t have to install the two Chutzpah plugins above. The one thing you’ll probably want to change however is how the tests are run, by default it will run them in the local browser, but you can change this to use the PhantomJS headless browser, which is installed with Chutzpah. Just go to Resharper->Options, then Tools->Unit Testing->JavaScript Tests and change the ‘Run Tests With’ setting to ‘PhantomJS’, then browse to the PhantomJS exe, which is in the Chutzpah NuGet package folder, so mine is set to ‘C:\myproject\packages\Chutzpah.2.5.0\tools\phantomjs.exe’ as below:


Where to put your unit tests?

There are a number of posts on Stack Overflow (see here, here and here for example) about where to put your JavaScript unit tests i.e. should they go in the same project that is under test or should they be in a separate project? Personally I like to keep my tests separate from the actual code and all of my C# unit tests are in a separate project in my solution file, so I’ve done the same for my JavaScript unit tests.

All you need to do is add a new ‘Class Library’ project to your solution and then add the Jasmine NuGet package to that project.

Running your tests

After installing Chutzpah and creating my first set of tests, I then attempted to run them, but no matter what I couldn’t get my tests to pass. After taking a step back and writing some very simple tests with no dependencies it turned out that I just need to make sure I’d included all of the necessary references in my unit test files.

Chutzpah runs all tests in a single file in isolation i.e. think of it like each of your C# unit tests which need to include any references with ‘using’ statements, so each unit test file has to reference any supporting JavaScript files it needs. References look like the following and should be placed at the top of your test file:

/// <reference path="../../../../myproject/scripts/libs/angular.js" /> 
These are file path references, relative from the tests project to the actual file location, the easiest way to create these references is to simply click and drag the file from the solution explorer into the JavaScript test file and Visual Studio will automatically create the reference for you.

In my tests I was including the references for Angular, Angular Mocks etc., but I hadn’t taken into account any other file references I may have needed, especially as they weren’t being used by the controller/service under test. It turns out that in my ‘App.js’ file I had some JQuery code running on start-up prior to my Angular app being created, which meant that in my tests I had to reference some extra files otherwise my Angular app module couldn’t be created and hence my tests would fail, which wasn’t entirely obvious from the test results (and of course I realise now that including non-Angular code in an Angular file was a bad idea!).

Here’s the list of references I ended up having to include, which as you can see is quite a lot for what was a simple unit test:

/// <reference path="../../../../myproject/scripts/libs/angular.js" /> 
/// <reference path="../../../scripts/angular-mocks.js" /> 
/// <reference path="../../../../myproject/scripts/libs/ui-bootstrap.js" /> 
/// <reference path="../../../../myproject/scripts/libs/sanitize.js" /> 
/// <reference path="../../../../myproject/scripts/libs/jquery-1.9.1.js" /> 
/// <reference path="../../../../myproject/scripts/libs/bootstrap-datetimepicker.js" /> 
/// <reference path="../../../../myproject/scripts/libs/jquery.validate.js" /> 
/// <reference path="../../../../myproject/scripts/app/app.js" />

Once I’d included the above references, my tests all ran fine as you can see in the following screenshot from the Resharper unit test session window:



Integrating your tests into your build

Chutzpah comes with a console application, which means that you can run your JavaScript unit tests from the command line, all you have to do is point it to the folder where your tests are, like so:

chutzpah.console.exe C:\MyProject\MyJavaScriptTests\

One issue I found is that Chutzpah will look for all JavaScript files in that folder and sub-folders, meaning that since we’ve installed Jasmine into our project, Chutzpah will also attempt to load and run those files, which we don’t want. Unfortunately Chutzpah doesn’t support filtering or wildcards in the folder path you specify, so the way I got around this was to place all of my tests into a subfolder and then adjust the command line to point to this folder instead, bypassing any files I didn’t want tested:

chutzpah.console.exe C:\MyProject\MyJavaScriptTests\Tests\


Adding Chutzpah to your Msbuild project

Since Chutzpah can be run from the command line, adding it to your build project is straightforward, all you need to do is create an ‘Exec’ task that executes the console application with the appropriate path to your JavaScript unit tests:

<Target Name="RunJSUnitTests">
  <Exec Command="&quot;$(SolutionFolder)\packages\Chutzpah.2.5.0\tools\chutzpah.console.exe&quot;
 $(SolutionFolder)\Tests.JavaScript\Tests\ /silent
 /junit $(MSBuildProjectDirectory)\chutzpah-output.xml" 
WorkingDirectory="$(SolutionFolder)\packages\Chutzpah.2.5.0\tools\" />

  <Message Text="$(TASK_BREAK)" />

Here’s the result of running the above build task on my system, if any of the JavaScript tests fail, Chutzpah will return an error and the build will fail:


Team City

Chutzpah automatically detects when it’s being run inside Team City and will change its output to the format understood by Team City, so as long as Chutzpah has been added to your Msbuild project, you don’t need to do anything to get support inside Team City as you can see from the following build log:



As you can see, there really aren’t that many steps involved in getting JavaScript tests setup in both Visual Studio and your build process, really the hardest thing for me was figuring out why my tests were failing and that was merely making sure my references were setup correctly, other than that everything was surprisingly straightforward, certainly more so than I was expecting when I started on this journey.

jQuery : working with SELECT lists

I’ve recently had to do some work with SELECT lists using jQuery and found the documentation to be a little sparse, there’s a few good articles out there, such as this one, but I couldn’t find any that had everything I needed so I thought I would share my experiences and provide a few examples to help others, so here goes.

(Disclaimer: I’m not suggesting that any of these snippets are necessarily the best or the fastest way to do things but they get the job done, your mileage may vary!)

To handle changes and get the currently selected value:

$("#mySelect").change(function (event) {

Retrieving the text of the currently selected option:

$("#mySelect option:selected").text();

With the above you could also remove the option and just do:

$("#mySelect :selected").text();

however I’ve always thought that jQuery selectors should be as specific as possible for performance reasons, hence why I use the former, though I doubt in this case that it would make any difference.

Finding an option by its value:

var listitem = $("#mySelect option[value=" + valueToFind + "]");

Finding an option by its text value:

// The following should work but doesn't in all browsers:
var listitem = $("select option[text='" + textToFind + "']");
// Since the above doesn't work in all browsers we can manually search 
// through all list items on the page
var listitem = null;
$("select option").each(function() {
    if ($(this).text() === textToFind) {
        listitem = $(this);

Retrieving all options:

var options = $("#mySelect option");

Removing all options:

$("#mySelect option").remove();

Removing the currently selected option:

$("#mySelect option:selected").remove();

Adding an option:

$("#mySelect").append("<option value=\"" + myValue + "\">" + myText + "</option>");

How many options are there:

var count = $("#mySelect option").length;

Hiding all selects on the page:

var selects = $("select:visible");

You may wonder why I assigned a variable before hiding the selects, well you’ll also notice that I only selected visible elements because if you’re hiding them to show an overlay (which you would need to do in IE6) then you’ll only want to show the selects that were visible before you showed your overlay, hence why they’re stored in a variable.

That should cover most of what you’ll need to do with SELECTS, if you spot any mistakes or anything that could be improved then let me know in the comments.