First: there is a plunkr example for the following code examples.

While doing some testing for a possible new project which we want to do in angularJS I discovered that its quite hard to implement a datatable which should have fully dynamic columns which can be reordered and toggled to display or not.

Many datatable implementations have either hard-coded columns which you can’t change at all or you can’t change the order of the columns in which they should be rendered. ngTable does it like that for instance.

So, I spent a rainy sunday afternoon to implement my own version and after much poking around and some frustrating moments, I finally got it.

The first hurdle I had to take was, that angularJS can’t handle directives that have a <tr> or <td> element as the root element of the directive. There is an issue for this where its explained that these elements need to be handled special, which jQuery does, but jqLite in angularJS does not. There is a pull request for this too, but its not accepted yet.

After discovering that, I wrote a little helper function to create the elements like this:

function createTDElement() {
	var table = angular.element('<table><tr><td></td></tr></table>');
	return table.find('td');
}

The next problem I had was to implement the full dynamic columns which should be customizable from an angular controller. I didn’t want just define a hard-coded table with some columns in a html file and manipulate the DOM elements after they were created by angularJS. I wanted to do it the angular way.

I decided that every column needs to have its own directive where the output inside the cells is defined. These directives are not known to the wrapper directive, but are part of the customization inside the controller, so the wrapper is fully generalized and can be used with any type and any number of columns. The wrapper directive adds additional elements into the DOM in the $compile phase of angularJS which have the correct column directives set to them dynamically.

The html in the view looks like this:

<table border="1">
    <tr ng-repeat="item in items" item="item" columns="columns">
</table>

Inside the controller you have something like this:

function myController($scope) {
   $scope.items = [//someitems];

  $scope.columns = [{
    id: "column2",
    title: "Manufacturer",
    directive: "secondcolumn",
    visible: true
  }, {
    id: "column1",
    title: "ID",
    directive: "firstcolumn",
    visible: true
  }, {
    id: "column3",
    title: "Country",
    directive: "thirdcolumn",
    visible: false
  }, ];
}

So in this case the table should render with 2 columns: column2 first, then column1 and column3 should not be visible. The property “columnDirective” is used to find out the directive that renders this columns html output.

$scope.items is the data object, that you want to display in the table.

The important parts of the column directive, which does all the magic, look like this:

function createTDElement(directive) {
	var table = angular.element('<table><tr><td ' + directive + '></td></tr></table>');
	return table.find('td');
}
app.directive('item', function($compile) {
  function createTDElement(directive) {
    var table = angular.element('<table><tr><td ' + directive + '></td></tr></table>');
    return table.find('td');
  }

  function render(element, scope) {
    var column, html, i;
    for (i = 0; i < scope.columns.length; i++) {
      column = scope.columns[i];
      if (column.visible) {
        html = $compile(createTDElement(column.directive))(scope);
        element.append(html);
      }
    }

  }

  return {
    restrict: 'A',
    scope: {
      item: "=",
      columns: "="
    },
    controller: function($scope, $element) {
      $scope.$watch(function() {
        return $scope.columns;
      }, function(newvalue, oldvalue) {
        if (newvalue !== oldvalue) {
          $element.children().remove();
          render($element, $scope);
          $compile($element.contents())($scope);
        }
      }, true);
    },
    compile: function() {
      return function(scope, element) {
        render(element, scope);
      }

    }
  };

});

(The implementations for the columns are missing here).

And thats it.

I created a plunkr which has an working example for this so you can play around with it.

Tell me if you know some way to implement this easier.

When developing unit tests in an angularJS app, you eventually stumble about a problem that can be quite frustrating to handle it in a clean und concisive way: promises.

Lets have a look at an example method in a controller:

$scope.method = function() {
    someService.loadData().then(function(data) {
       $scope.data = data;
    }
}

This method is calling loadData() on an angularJS service which is returning a promise, which could be resolved only after a $http call is finished.

How to handle that in a unit test?

Clearly, you should mock someService, thats easy. But what to do with the promise? In my first couple of tests, I tried to reimplement promises somewhat and ended with ugly constructs like this:

someServiceMock = {
    loadData: jasmine.createSpy().andCallFake(function() {
        then: jasmine.createSpy()
    }
}

This way I had to call the resolve or reject functions in my test manually, like so:

it('should be a lot easier', function() {
   controllerScope.someMethod();

   resolveFunction = someServiceMock.loadData().then.mostRecentCall.args[0];
   resolveFunction('resolveData');

   expect(controllerScope.data).toBe('resolveData');
});

That worked, but its ugly as hell.

So, after some studying with google I just refactored my tests with a much simpler solution, which uses the original $q service to resolve promises and calls the appropriate function arguments automatically.

Defining the mock service changes a bit and needs to be in an inject function as $q service is needed:

beforeEach(function() {
    inject(function(_someService_, _$q_, _$rootScope) {
        var deferred = _$q_.defer();
    
        someService = _someService;
        rootScope = _$rootScope_;
    
        deferred.resolve('resolveData');
        spyOn(someService, 'loadData').andReturn(deferred.promise);
    })
})

it('is now a lot easier', function() {
   controllerScope.someMethod();
   rootScope.$apply();
   expect(controllerScope.data).toBe('resolveData');
}

The loadData() spy is now always returning a resolved promise.

Of course, you can (and maybe should be) resolve the promise in the test itself if the data is different when you have more than one test.

The catch is though, that you need to call rootScope.$apply() method manually in your test as promises only get resolved during a angular $digest phase. After this method is finished, all promises are really resolved and you can test for the expected outcome.

When trying to mock the angularJS internal $window factory, I recently stumbled about an error message when running the test:

TypeError: Cannot read property 'userAgent' of undefined
	    at $SnifferProvider.$get (C:/projects/hwa-mobile/src/main/external-libs/angular.js:8327:72)
	    at Object.invoke (C:/projects/hwa-mobile/src/main/external-libs/angular.js:2864:28)
	    at C:/projects/hwa-mobile/src/main/external-libs/angular.js:2702:37
	    at getService (C:/projects/hwa-mobile/src/main/external-libs/angular.js:2824:39)
	    at Object.invoke (C:/projects/hwa-mobile/src/main/external-libs/angular.js:2842:13)
	    at C:/projects/hwa-mobile/src/main/external-libs/angular.js:2702:37
	    at getService (C:/projects/hwa-mobile/src/main/external-libs/angular.js:2824:39)
	    at Object.invoke (C:/projects/hwa-mobile/src/main/external-libs/angular.js:2842:13)
	    at C:/projects/hwa-mobile/src/main/external-libs/angular.js:2702:37
	    at getService (C:/projects/hwa-mobile/src/main/external-libs/angular.js:2824:39)

The test looked something like this:

describe('myService', function () {
	beforeEach(function () {
		module("myModule",function ($provide) {
			$provide.factory('$window', function () {
				return jasmine.createSpy('$windowmock');
			});
		});
		....
	});

	it('should do something', function () {
		...
	});
});

Apparently angularJS itself tries to read the userAgent even when running inside a mocked environment.

The solution was quite easy:

describe('myService', function () {
	beforeEach(function () {
		module("myModule",function ($provide) {
			$provide.factory('$window', function () {
				var windowmock = jasmine.createSpy('$window);
				windowmock.navigator = window.navigator;
				return windowmock;
			});
		});
		....
	});

	it('should do something', function () {
		...
	});
});

The navigator property of the jasmine mock object will be the original navigator property of the original window object. Smells a bit, but works.

• personal loan lenders
• best payday loans
• fast loans
• fast loan
• online loans

I did it all wrong in my first angularJS application. Oh I did it really wrong!

The structure of my first angular project looked something like this:

Root folder

js

controllers

Somecontroller.js

Anothercontroller.js

controller.js

directives

Firstdirective.js

SecondDirective.js

directives.js

services

AService.js

BService.js

services.js

app.js

index.html

partial1.html

partial2.html

So, all controllers were going to “controllers” folder, services into “services” folder and partials lived directly next to full html files. When we started to have more than 10 directives and 5 services the problems with this approach were really backfiring:

• it was not easily visible what files were depending on what other files
• refactorings were thus quite hard
• reusing features in other code/applications was hard as the structure didn’t allow to group files of a single feature together
• it was hard for new developers to understand the flow of the application
• it was hard to extend the application so that it not only consisted of one (single page) application but of two applications that shared some features

Since then I tried a few different approaches and while experimenting with ngStart as a skeleton for new angular projects I’m now settled with an approach I want to use in all my next projects.

What I came up with, is an approach that groups features into angularJS modules. The main advantages is that the code structure is based on features of the application and every feature is defining its own angularJS module. The angular root module then is the glue and binds all modules together.

The structure of ngStart looks like this:

Root folder

modules

contact

contact.js

contact.html

ContactController.js

ContactService.js

about

about.js

about.html

AboutController.js

app.js

index.html

The main idea is that every folder under “modules” is by definition an angular module. The module is always declared in a javascript file that is named like the folder (“about” -> about.js) and is the name of the module too.

Each angular module can use the full list of angular features. It can have its own angular.config() phase function, can declare its own routes and can have its own list of dependencies.

To refactor a certain feature you now know exactly where to begin and what files are directly dependent on each other when they implement a single feature. You can move modules around and even move them out of the your first single-page app, make another app and declare a dependency on the module to reuse your code.

In a small and trivial example the advantages of this approach are not easily visible, but as soon as a team of developers works together on an application it will grow very fast.

In enterprise applications there is usually a software architect who defines a structure which the team has to follow. Programming languages in the backend also have features to structure code in packages or modules and import it. Javascript doesn’t. And often times the software architect doesn’t care about javascript or the frontend at all. And frontend developers tend to not care about it neither as tools were missing in the past and there wasn’t really a need for it when writing jquery scripts.

But as frontend engineers or frontend developers of today, you should care! AngularJS is great. But angularJS applications will face the same problems as every other application that begins to grow. And your structure should make it easy to grow and adapt. You should care from the beginning!