Browse Tag: javascript

A high level look at Angular 2

Developed by Google, Angular 2 is the newest version of the popular Single Page Application (SPA) framework. Angular 2 is a step in a new direction compared to previous versions, but has keep all the best characteristics and “lessons learnt” to deliver a fast, fully featured and rich ecosystem.

About Angular 2

Angular 2 impacts your whole application, or at the least, a section of it, rather than specific pages. Angular 2 is best suited to new (“greenfield”) development, as it can be relatively tricky to migrate legacy code (Angular 1.x code) to the new version. Angular 2 has new concepts, syntax, methodologies, and opinions, but is comparable to as previous versions in the way it works.

If you have been following Angular development since “the early days” of beta 1, then its been a very rocky road for you. Even now (this post was written around the release of RC5), the API is still evolving and new features are being added. Whilst this experience has been hard for early adopters, I believe the end result will be a fantastic, easy to use, and performant framework with a lower barrier to entry for all.


The purpose of this post is to discuss the core concepts of Angular 2. We’re not looking to dive into the details at this point, a follow up post on that will come later. We will discuss; pre-processors, build tools, components, dependency injection, interpolation, pipes, directives, event bindings, two way data binding, lifecycle hooks, routing, services and the HTTP client.

I have a side project on Github, named Angular2Todo, which is an Angular 2 todo application written with Angular 2, Universal Angular, and ASP .NET Core. If you’re interested in server side rendered Angular, please check that out.

This post is based on my own experience with Angular 2, and most of the knowledge has come from developing real world applications, including this one on Github.

Going forward, we will refer to Angular 2 simply as “Angular”. Old versions of Angular will be referred to by their version number explicitly.

TypeScript, Babel, ES6/ES5

It is hard to talk about Angular 2 without discussing TypeScript (See TypeScript playground for a live interactive demo). Angular was originally written using AtScript, which was an extension of TypeScript (TypeScript with additional functionality). However, after much collaboration between the Angular team and the TypeScript team, it was decided to use TypeScript exclusively instead.

Angular is written using TypeScript, however, you don’t necessarily have to write you Angular code using TypeScript, you could use; Babel, ES5 or ES6 if you prefer. If you are familiar with Google Dart, that is also supported.

I believe that Angular 2 applications are most commonly being developed using TypeScript, so I’ll use TypeScript throughout this post. If you need a summary of TypeScript, check out my TypeScript Beginners Guide on this website,

At a high level, TypeScript is JavaScript. You can convert all your existing JavaScript code to TypeScript as easily as changing the file extension from JS to TS. The most useful feature of TypeScript is its transpiler, which takes your TypeScript code (which is basically ES6), and converts it into ES5. Why would you want to do this? Most developers will want to utilise the new language features of ES6, ES7 and beyond, whilst not having to worry about cross browser compatibility. Support for ES6 is shaky at best on the desktop (Microsoft Edge, I’m looking at you), and very poor across mobile devices. TypeScript takes this pain away by converting your code to ES5, which is stable and does have excellent support.

Build tools

As we’re working with TypeScript, and potentially other tools as well, it makes sense to use build tools like Webpack or Gulp. Build tools can automate repetitive tasks, such as; transpiling the code (TypeScript to ES5), bundling (taking all your individual assets and merging them into one big file), minification (compressing that file for faster delivery to the client), and injection (referencing the new resource in the HTML).

Build tools can also watch your changes, and automatically build and refresh the browser automatically, so that you can focus on writing code and developing your application.

The Angular documentation, once you get beyond the absolute basics, encourages you to split your components (we will discuss these more next) into individual concerns. Your JavaScript, styles (CSS) and markup (HTML) are to be placed in individual files (component.js, component.css, component.html). This results in a lot of “chatter” between the client and server and can slow down the user experience (particularly on slower, mobile devices). Build tools can solve this problem by automatically injecting the markup and styles into your JavaScript files at compile time. This is certainly not a task you would want to perform manually!

Personally I have worked with both Gulp and Webpack when developing Angular applications. I prefer Webpack for how well it works, but I do not like the configuration aspect. Gulp is much easier to configure, but not as powerful (my feeling) as Webpack.

I have an example Gulp and Webpack configuration file on GitHub, that have both been used in real world applications.


Components are the basic building blocks of all Angular applications. Components are small and have their own state per instance (meaning you can reuse the same component many times on a single page without it colliding with other instances). Components closely follow the open standard for Web Components, but don’t have the same pain of cross browser support (the Web Components standard has not been finalised yet). Components are a group of directly related JavaScript (logic), CSS (style) and HTML (markup), which are largely self contained.

Components in Angular are defined using the @Component class decorator, which is placed on a class, and take “metadata” which describe the component, and its dependencies.

A component might look like this;

import { Component } from '@angular/core';
import { ROUTER_DIRECTIVES } from '@angular/router';

    selector: 'my-app',
    directives: [...ROUTER_DIRECTIVES],
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.css']
export class AppComponent {


This is ES6/TypeScript code. We create a class, called AppComponent using the class keyword. The export keyword makes the class “public”, so that it can be referenced elsewhere throughout the application.

The @Component directive takes an object that describes the component.

  • Selector: This is used in your markup. The selector is how you refer to the component in HTML. In this example, the code would be; <my-app></my-app>
  • Directives: These are other components that you want to utilise in the components markup
  • TemplateUrl: The path on the file-system to the markup
  • StyleUrls: A string array of all the CSS files used to style the component

There are many values that can be passed in here, the main values are displayed.

About styling

Why does Angular load the styles in this manner? Take the following markup (I’ve trimmed this slightly for simplicity);

    <td>{{asDate( | date}}</td>
    <td>{{asDate(calibrationDue.expiration) | date}}</td>

This is pre-compiled markup. The compiled, rendered markup looks something like this (again trimmed for simplicity);

<tr _ngcontent-dqf-10="" class="pointer">
    <td _ngcontent-dqf-10=""></td>
    <td _ngcontent-dqf-10="">Sep 29, 2014</td>
    <td _ngcontent-dqf-10="">Sep 29, 2016</td>
    <td _ngcontent-dqf-10="">AA11AA</td>
    <td _ngcontent-dqf-10="">John Smith</td>
    <td _ngcontent-dqf-10="">John Smith Transport</td>
    <td _ngcontent-dqf-10="">Ford</td>

Notice this rather auto-generated looking attribute that has been added to the markup? Well, it was auto-generated by Angular. The same attribute was also injected into the CSS. Why? to scope the CSS, to prevent it from having any effect on any other aspect of the site outside of the component itself. Any CSS you write in your CSS file, which is referenced by a component, cannot affect any other component or any other part of the site. The styles only affect the component itself. This is tremendously powerful and will result componentized CSS, but CSS that effectively does not cascade.

Angular 1.5+

Components were introduced in Angular 1.5 to help ease the transition (the upgrade path) from Angular 1 to Angular 2. If you are writing Angular 1 code currently and are looking to migrate to Angular 2 in the future, then consider re-writing your existing controllers into components to make your migration simpler in the future.

Dependency injection

Dependency injection in Angular is similar, in my experience, to dependency injection in many other languages/frameworks. Angular takes over managing the lifecycle of a components (or services) dependencies, and dependencies of those dependencies.

When you need to use a dependency, a service for example, you inject it into your component through the constructor. Dependency injection example;

import { Component, OnInit } from '@angular/core';
import { TodoStore, Todo } from '../services/todo.service';

  selector: 'app-footer',
  template: require('./footer.component.html')
export class FooterComponent implements OnInit {
  constructor(public todoStore: TodoStore) {

In the above example, our component needs to ues the TodoStore. Rather than creating a new instance of it inside the constructor, we add it as a parameter to our constructor. When Angular initialises our component, it looks at these parameters, finds an instance, then supplies it to the component.

Dependency injection in Angular is hierarchical. When the component needs a dependency, Angular looks to the components ancestors (parents, grandparents etc) until an instance is found. Depending on how you construct you application, dependencies can be (and probably will be) singletons. However, as dependency injection in Angular is hierarchical, it is possible to have multiple instances of the same service. When dependencies are defined at the “root level” of the application, the service will always be a singleton.

Angular takes care of initialising the dependency, and the dependencies of the dependency, so you only need to worry about using the dependency and not worry about managing it.

In the above code example, we are “referencing” each dependency using its type, therefore we don’t have to concern ourselves with making our code “minification safe”. In Angular 1, we define all our dependencies in a string array ($inject) so that Angular knows the names of each dependency at run time even after the code has been mangled. This step is no longer necessary.


Why would you want to handle dependencies in this way? Code complexity is reduced, and we can make our unit tests simpler. How? When using testing we can tell Angular to inject mock versions of our dependencies, to speed up the tests and ensure we’re only testing our own code and not Angular itself.

If you inject HttpClient into a service, for example, you would not want to make real HTTP requests to the server when running your tests. Instead, you inject a mock version of the HTTP client and simulate the request/response, for faster, consistent results.


Perhaps the most familiar concept in Angular, interpolation. Interpolation is the means of evaluating expressions, and displaying the results.

Take the following example;

<div class="view">
  <input class="toggle" type="checkbox" (click)="toggleCompletion(todo)" [checked]="todo.completed">
  <label (dblclick)="editTodo(todo)">{{todo.title}}</label>
  <button class="destroy" (click)="remove(todo)"></button>

The interpolation code is on line 4, {{todo.title}}. There is an object on the component, called todo. The object is a complex object, so it has many properties (and functions). In this case, we want to display the title of the todo to the user. Angular looks at this expression, determines the value of todo.title and renders it on the view. Whenever the value changes, that change is evaluated and displayed automatically.

You can display the results of practically any expression. Take another example; {{2+2}}. The result is 4, so 4 will be displayed on the view.

It is also permitted to invoke functions in interpolation expressions. The following code is perfectly valid;

{{ getTheCurrentDate() }}

As long as the component has a function called getTheCurrentDate, Angular will invoke it and display the result. You should avoid calling functions when possible as Angular will evaluate them more frequently than you expect, which can hurt performance when the functions do a lot of work. Instead, favour properties that do not change frequently.

Angular has a dependency on another open source project, called Zone.js. Zone.js handles change detection, and informs Angular when changes occur. Talking about Zone.js is out of scope of this post.


Pipes are usually used in conjunction with interpolation. Pipes, known as filters in Angular 1, are used to format data.

For example;

    {{todoStore.todos | json}}

The above code takes the array of todos, and converts it to a string and displays that result in the view.

The following are pipes built in to Angular;
* Async – Automatically subscribe to observables, which are used extensive in Angular (Angular has a dependency on RxJS).
* Date – Used to format a date object. For example; Sunday 21st August 2016.
* Percent – Used to display a number as a percentage, can pass in the number of decimal places to show.
* JSON – Used to “toString” JavaScript objects
* Currency – Format numbers as currencies ($10.99 or £10.99)

Notice there is no OrderBy pipe in the list, like there was in Angular 1. That is because ordering was a particular pain point in Angular 1. Because of the way that Angular 1 detected changes, the ordering would often occur multiple times, which when working with large data sets killed performance. The Angular team have excluded the OrderBy pipe in favour of ordering being done by your code, within the component or service.

There are some other less important pipes, but generally there is significantly less built in pipes than in previous versions. This was a deliberate choice to keep the code base lean and clean.

Structural Directives

Structural directives directly affect the structure, or the elements within, the DOM (Document Object Model). Structural directives can add DOM elements, remove them and modify them.

The most commonly used structural directives are;

  • ngFor, which is used to loop through items in an array
  • ngIf, which adds/removes an element to/from the DOM depending on the result of an expression

The syntax for structural directives is different from the norm. Structural directives are prefixed with an asterisk (*). Take the following code;

<footer class="footer" *ngIf="todoStore.todos.length > 0">
    <span class="todo-count"><strong>{{todoStore.getRemaining().length}}</strong> {{todoStore.getRemaining().length == 1 ? 'item' : 'items'}} left</span>
    <button class="clear-completed" *ngIf="todoStore.getCompleted().length > 0" (click)="removeCompleted()">Clear completed</button>

The structural directive is shown on line 1. *ngIf="todoStore.todos.length > 0". If the expression evaluates to true, then the footer is rendered, and all expressions within are rendered too. When the expression evaluates to false, the DOM element and all of its children are thrown away, removed from the DOM. This is to save Angular from having to evaluate code that the user is never going to see.

Below is an example of ngFor;

<ul class="todo-list">
    <li *ngFor="let todo of todoStore.todos">
        <app-todo [todo]="todo"></app-todo>   

On our component, we have a collection of todo, which contains zero, one or more items. For each todo in the collection, a new <li> is created. Angular scopes the <li> with the todo, so that any child element within the <li> can make use of the todo. In this example, the todo is passed to another component, called TodoComponent, whose responsibility is rendering single todo‘s to view.

In a nutshell, ngFor is a loop. Each iteration of the loop creates a new element which “knows” about the current item.

Attribute Directives

Next, we have Attribute Directives, which are responsible for changing the appearance of DOM elements. When using this square-brackets syntax, it “feels” like manipulating the DOM in JavaScript.

Consider the following code sample;

    <p [style.background]="backgroundColor">Hello,!</p>

The backgroundColor is a property on the component. In code, we can set the value of backgroundColor to be a color (yellow, or #ffff00 for example). The end result will be an inline style being applied, with the background property set to yellow.

Here is a screenshot on the compiled code at run time;

Angular 2 - Attribute directive run time example

You are not limited to manipulating the style of the element, you can change just about any property of the element.

Take another example;

<li *ngFor="let todo of todoStore.todos" [class.completed]="todo.completed" [class.editing]="todo.editing">
    <app-todo [todo]="todo"></app-todo>   

In this example, we are adding the CSS classes completed and editing to the element when todo.completed or todo.editing is true. Likewise, when false, the classes are removed.

Again, we could control the checked state of a Check Box (input field with a type of checkbox).

<input class="toggle" type="checkbox" (click)="toggleCompletion(todo)" [checked]="todo.completed">

When todo.completed is true, the Check Box is checked, otherwise, it is not checked.

Event Bindings

Event bindings are used to listen for user interactions, or events that get raised when the user interacts with the page or an element. Some events you may be interested in responding to; clicks, mouse moves, focus, blur, etc.

Event bindings are added to DOM elements and are denoted with brackets. Angular keeps an internal list of all the events it understands. If you try to listen for an event that it doesn’t map, Angular will look to your code instead (you can define your own custom events).

When an event occurs, typically a function on your component is invoked. You can pass arguments to the calling fuction, such as state, the event object, DOM elements, arbitrary values and more. It is also possible to pass state from one component to another using this mechanism.

Take the following example;

<label (dblclick)="editTodo(todo)">{{todo.title}}</label>

When the user double clicks on the label, the editTodo function is invoked. In this example, this element has a todo in scope, which is passed as an argument to the function.

Another example;

<input class="edit" *ngIf="todo.editing" [(ngModel)]="todo.title" (blur)="stopEditing(todo, todo.title)" (keyup.enter)="updateEditingTodo(todo, todo.title)"

In this example, we are responding to the blur event (when the control loses focus) and key-presses (enter, escape) so we can perform an appropriate action when the user presses these keys on their keyboard.

Two way data binding

Two way data binding is primarily used when binding input controls to properties on the component. When using a two-way data binding, when a user interacts with a form (types data into a text field) that change is automatically reflected on the component. Likewise, if a property that is bound to an input field is changed in code (either by the component itself, or by something else, say an Observable being resolved) that change is reflected in the view immediately. Two way data binding is a mechanism for synchronising data between the view and the component.

To utilise two way data binding, you use ngModel. The syntax for correct use of ngModel is known as the banana in a box syntax (click the link for a full explanation as to how the name came about).

In reality, the banana in a box syntax is an amalgamation of and attribute directive and an event binding (and combination of the two). Banana in a box syntax is syntactic sugar for two mechanisms being used together, which helps you write less code.

Take the following example;

<input class="new-todo" placeholder="What needs to be done?" autofocus="" [(ngModel)]="newTodoText" (keyup.enter)="addTodo()">

When the value entered into the input field changes, the property newTodoText is automatically updated.

Now consider the long hand version of the same code;

<input class="new-todo" placeholder="What needs to be done?" autofocus="" [ngModel]="newTodoText" (ngModelChange)="newTodoText=$event" (keyup.enter)="addTodo()">

A separate event is needed to assign the new value to the property on the component ($event).

By combining the attribute directive and event binding, the code is more readable. The less code we can write, the easier our application will be to maintain over time.

Lifecycle Hooks

Lifecycle hooks can be thought of as events that get raised at key points during your components lifecycle. Lifecycle hooks are callback functions that are invoked by Angular when the component is in various transitional events.

Put another way, lifecycle hooks help you to execute code at the right times during the initialisation and destruction of your components.

Lets say your component needed to request some data from a HTTP endpoint. Where do you put code like that? In the constructor? No, ideally the constructor should be kept as clean as possible and should only initialise variables at the most. Having your constructor do a bunch of work will probably make your application run more slowly. Ideally what you need is a “load event”. Lifecycle hooks provide this. Lifecycle hooks help you execute code at the right time.

The most commonly used lifecycle hooks;
* ngOnInit: The “load event”
* ngDoCheck: Raised when Angular is running its internal change detection
* ngAfterViewInit: Raised when the component view has finished initialising
* ngOnDestroy: Called when the class is being destroyed/cleaned up

Side note; TypeScript has a construct called interfaces. If you come from a .NET background, interfaces in TypeScript are the same as what you already know. For everybody else, interfaces can be best thought of as “contracts”, which promise that the class that implements the interface also implements all the properties/functions defined on the interface. If a class implements an interface, and that interface has a function defined called ngOnInit, then the compiler can guarantee that function has been implemented on the class. (If not, a compile time error is emitted). Angular exposes an interface, called OnInit, that has a single function defined, called ngOnInit. Implementing this interface is best practice, but not mandatory. Just having the function in your class is good enough.

Example usage:

import { Component, OnInit, Input } from '@angular/core';
import { TodoStore, Todo } from '../services/todo.service';

  selector: 'app-todo',
  template: require('./todo.component.html')
export class TodoComponent implements OnInit {
  ngOnInit() {
      //"load" logic goes here

Some time after the instance of the component has been created, Angular will invoke the ngOnInit function, assuming it exists, enabling you to run custom logic (and call that HTTP endpoint, if that is what you need to do).


Routing is how the user gets around your Angular application. Routing is navigation between views/components. State, in the form of parameters, can be passed between views and can be injected into your components. A route is a combination of a path and a component. Routes are referred to by their path in your markup using the routerLink attribute directive.

Example usage;

<a routerLink="home" routerLinkActive="active">Home</a> | <a routerLink="about" routerLinkActive="active">About</a>

The above code sample also shows the use of the routerLinkActive attribute directive. This directive applies a CSS class to the element it is applied to when that route is active. The routerLinkActive directive works in conjunction with the routerLink directive, so that when the route referenced by the directive is active, the custom CSS class (in this case, called active) is applied to the element. Typically, you would want to change the visual appearance of the DOM element to indicate to the user that they are on a particular page.

Routing in Angular has been on a roller-coaster ride of changes throughout the alpha, beta and release candidate (RC) phases. The current iteration of the router uses a hierarchical router configuration approach to define routes, child routes, and to enable deep linking. For the sake of simplicity, we won’t discuss hierarchical routing/deep linking in this post, but be aware that it can be achieved by having multiple route configuration files at different levels of your applications. Child routes are extensions of their parents route.

Router configuration

To define the main routes of the application, we create a RouterConfig object, which is an array of routes. Most routes consist of a path and component. Other routes can have additional properties, like wildcard routes, which decide what to do when the user navigates to a path that does not exist (using the redirectTo property).

Example usage;

import { RouterConfig } from '@angular/router';
import { HomeComponent } from './components/home/home.component';
import { AboutComponent } from './components/about/about.component';

export const routes: RouterConfig = [
    { path: '', redirectTo: 'home', pathMatch: 'full' },
    { path: 'home', component: HomeComponent },
    { path: 'about', component: AboutComponent },
    { path: '**', redirectTo: 'home' }

Here we have four routes defined;

  • Default route: No path is defined, so when the user hits the page with no route parameters, they are redirected to ‘home’ (defined next).
  • Home route: Displays the HomeComponent.
  • About route: Displays the AboutComponent.
  • Wildcard route (**): When the route is not recognised, the user is redirected to the ‘home’ route. This is a catch-all.

The RouterConfig object is then referred to in the applications bootstrapper (loads the application and its component parts, called bootstrap).

Example usage (some code omitted for brevity);

import { provideRouter } from '@angular/router';
import { routes } from './routes';

bootstrap(AppComponent, [

The provideRouter function is exposed by the Angular router, and takes the RouterConfig object we just created.

More router directives

Angular also helps control navigation with several additional directives.

  • routerOutlet: Tells Angular where to put the view/component (used within the application shell, typically the AppComponent).
  • CanActivate: Allows navigation to be cancelled (useful for restricting access to certain pages under certain circumstances, like trying to access a page when the user is not logged in).
  • CanDeactivate: Runs before the route is changed, and can also cancel navigation (useful when, for example, prompting the user to save changes they have made to a form).

Angular does not “just know” about these directives, as everything router related lives within its own module. You must import the directives into your AppComponent‘s directives array;

import { Component } from '@angular/core';
import { ROUTER_DIRECTIVES } from '@angular/router';

    selector: 'app',
    directives: [...ROUTER_DIRECTIVES],
    template: require('./app.component.html'),
    styleUrls: ['./app.component.css']
export class AppComponent {


The ROUTER_DIRECTIVES constant is a shortcut (an array, which includes all the directives previously discussed) to keep the code a bit cleaner.


To end on a lighter note, services a reasonably straightforward in Angular. Services are classes that have the @Injectable decorator applied to them. The @Injectable decorator tells Angular that the class can be injected into components/directives/other services etc.

Services are used to share and abstract common functionality between one or more components. Services can help reduce code complexity and duplication. Depending on the configuration of your application, (remember the hierarchical dependency injection?), services can be singletons and maintain state over the lifetime of the application. Services can also have their own dependencies, which is handled the same way as how dependencies for your components are handled.

Example usage;

export class TodoStore {
    //Implementation omitted   

I like to use services to add additional abstraction to some built in Angular services. Why? If the Angular API changes (and it has changed a bunch in the past), I have a single place where I have to make changes and get back up and running quicker.


Angular 2 is an opinionated web application framework for developing single page applications (SPA’s), and is actively developed by Google. Angular 2 is a move away from the original framework, it introduces and syntax’s and a “new way of doing things”. Important problems with past versions have been overcome (change detection/dirty checking was a major flaw of Angular 1) and the framework is taking a new direction. Whilst it is possible to write Angular 2 code in many ways, the preferred approach is to use TypeScript. There is a learning curve involved, the tooling especially is very much in its infancy, but once over the initial hump Angular 2 can be a fantastic framework when used in the manner it was intended for.

What I learnt from using TypeScript “for real”

I completed my first commercial Greenfield project using TypeScript over plain old JavaScript throughout, and there were some frustrations along the way.



  • TypeScript is awesome, for sure, but there needs to be improvements to tooling to streamline the experience.
  • TypeScript is strongly typed of course, but it doesn’t force you to code in this manner, which can result in shoddy code.
  • Tweaking is required to make bundling work properly.


Tooling Frustrations

When I started the project, I was using Visual Studio 2012 Update 4 with TypeScript 1.0 pre-installed.  I was brought in to work on this project on a short term basis, and this is how the machine was set up when I arrived.  Normally I wouldn’t choose to use Visual Studio 2012 (I like to use the latest tools where possible) but I decided to just go with it and make do.  Once deficiencies in tooling became clear, I did eventually push for an update to Visual Studio 2013 Update 4, which in fairness resolved most of my frustrations.

I have a license for JetBrains ReSharper, which has support for TypeScript 1.4 (and indeed that is the default setting when using ReSharper 9).  This was actually my first tooling problem.

When using Visual Studio 2012, you are using TypeScript 1.0 (unless you have proactively updated to version 1.4).  Naturally 1.0 is an older version and doesn’t support language features such as protected methods or ECMAScript 6 template strings.  ReSharper, however, does understand these features and offers suggestions to use them.  Trying to use these features results in build errors, which of course was confusing because I didn’t understand that I was actually using version 1.0 at the time (does it say anywhere? not to my knowledge).

Also, due to the aforementioned old version of TypeScript, I also encountered an issue with TypeScript definition files.  These files are designed to not only provide IntelliSense in Visual Studio when working with third party libraries such as AngularJS, but also are used during the build process for compile time checking.  Because the TypeScript definition files (sourced using NuGet via GitHub) were based on TypeScript 1.4, again hundreds of errors at compile time.  Interestingly, however, with version 1.0 it was actually possible to ignore these build errors and still generate the compiled JavaScript files.  Only once upgrading to version 1.4 later on did it become mandatory to fix these build issues.

Compile on save does what it says on the tin.  You write some TypeScript code, click Save, and the JavaScript file is generated automatically.  Well, actually, no.  There were dozens of occasions when this just didn’t work.  I had to literally open the scripts folder, delete the JavaScript files manually, re-open Visual Studio, and save the TypeScript file again before it would actually recompile the JavaScript file.  This was tedious and boring and didn’t seem to be resolved by upgrading to Visual Studio 2013 Update 4 (although it did become less frequent).  I have Web Essentials installed, which gives you a side by side view of the TypeScript and JavaScript files which I originally turned off.  I did eventually turn this back on so I could see if the files were being recompiled at a glace before refreshing the web browser.

On a side note, the tooling provided by Google Chrome developer tools is excellent.  You can debug the actual TypeScript source directly in the browser, and if you inadvertently set a breakpoint on a JavaScript file, Chrome will navigate you back to the TypeScript file.  Nice.


Bundling in MVC

The project I was working on used some features of ASP .NET and Web API.  One such feature was bundling and minification, which I always use to improve performance and reduce server load.  I wrote many based files and interfaces as you would expect, as both are fully supported in TypeScript.  However, what I later realised (perhaps I should have realised at the start, but hey) was that order is important.  The MVC bundler doesn’t care about order, so there’s a big problem here.  After switching on bundling, I went from 0 runtime errors to at least 20.  There are two approaches I could have taken to resolve the problem;

  1. Create two separate bundles, one for base classes, the other for derived classes (I don’t care for this)
  2. Create a custom orderer and use naming conventions (prefix base class files with the name “Base”) to ensure order.

I went for the latter option.  This involved having to rename all my base class files and interfaces (granted interfaces don’t actually generate any JavaScript, but I wanted to keep the naming consistent) and writing a custom convention based orderer.  Neither of these things were challenging, just time consuming.


TypeScript is inconsistent

I can only speak from my own experiences here.  I don’t claim to be a TypeScript or JavaScript master, I’m just a normal developer as experienced as anybody else.

I love the strongly typed nature of TypeScript, that’s the feature that appeals most to me.  I do however have the following qualms;


TypeScript does not force you to use the language features of TypeScript

This is either a good thing, or a bad thing.  I can’t decide.  To be honest, I wish TypeScript did force you to use its own paradigm.  You can easily write pure JavaScript inside a TypeScript file and it will all compile and “just work”.  This is a bit of a downfall for me because I’ve always found JavaScript to be frustrating at best (can you think of an application you’ve written in JavaScript that hasn’t eventually descended into mayhem?).

What I mean is this, I can create a local variable and assign it a type of Element;

var element : Element = angular.element('.myelement')

The type constraint is redundant, and ReSharper makes a song and dance about the fact and basically forces you to get rid of it (yeah, I know I could turn this off but at the end of the day ReSharper is right).  I can assign function parameters type declarations, but I don’t have to.  (I did eventually go back in fill these in where I could).  I know that I should use type declarations and to be honest I wish I did use this feature more, but I’m lazy.  Next time I’ll be sure to do this from the start as I think it adds further structure to the code.


TypeScript doesn’t know it all

The project I was developing was built in conjunction with AngularJS.  I’ve had an up-down relationship with AngularJS to say the least, but I decided to fully embrace it this time and not switch between jQuery and Angular (yeah I’m aware that Angular uses jQuery lite under the hood, I’m referring to not switching between using $() and angular.element()).  I made heavy use of Angular Scope and I often had a dozen or more child scopes running on any one page.  So as a result, I had lots of code that looked roughly like this;

var scope = angular.element('.myselector').first().children('.mychildren').scope()

That’s perfectly valid code.  Even though I have already added the appropriate type definition files and referenced appropriate at the top of the file, TypeScript still insists that scope() is not valid in this context and I get a compilation error.  So I’d have to exploit the dynamic functionality of JavaScript to get around this;

var children = angular.element('.myselector').first().children('.mychildren');
var scope = children.scope();

Ok its not a big deal.  The scope variable is now of type any, so there’s no IntelliSense and no compile time checking.  But hey, wait, isn’t that the main point of using TypeScript in the first place?  Now if I pass scope to another function, I’ll exacerbate the problem (due to the fact that the parameter will have to be of type any) and before you know it, I’m just writing JavaScript again.  Fail.

Positive note

I’ve ranted about what I don’t like about TypeScript, and the frustrations I’ve encountered so far, but honestly I can’t sign its praises enough.  I estimate that so far TypeScript has saved me at least 3 million hours of effort.  Ok, perhaps a slight exaggeration, but you get the point.  Writing TypeScript is easy and familiar because I am comfortable with JavaScript and strongly typed languages such as C#.  I did spend perhaps a few hours reading the documentation and experimenting in the excellent TypeScript playground (both of which are excellent by the way), but generally thanks to previous experience with the aforementioned languages, I found that I “just know” TypeScript and it has a very smooth learning curve.



TypeScript is awesome, there is no doubt in my mind about that.  TypeScript saves all the pain that naturally comes with JavaScript and its only going to get better over time.   The tooling issues and inconsistencies are relatively insignificant, once you get used to them.

8 things every .NET developer must understand

You’ve been in your current job for a while now, and you’re really starting to get good at what you do.  You’re perhaps thinking about finding something new, and you’re wondering what sort of questions a potential new employer might ask.  I’ve been interviewing a lot recently and I have noticed there are 8 questions that get asked a lot.  Spend some time and make sure that you understand each point in turn, doing so will help make that dream job become a reality.

SOLID Principals

The ultimate acronym of acronyms.  You’ve heard of it, but do you know what it stands for? Do you really understand what each principal means? Yeah thought so.  This awesome video by Derick Bailey will clear things up a lot for you;

Garbage Collection & IDisposable

One of the best features of developing with any .NET language is the lack of effort you have to put in to garbage collection.  You generally don’t have to care too much about 1st/2nd/3rd gen collection cycles, de-allocating memory or anything like that.  Its still a very important topic, however, and every .NET developer should understand how it works.

Once you become a more experienced developer (and I’m especially talking to WPF developers here) you quickly learn that memory management isn’t a forgotten topic.  Failure to unsubscribe from events, failure to close streams, and keeping hold of large objects (say instantiating them in a loop that never ends) is a sure-fire way to balloon up your apps memory usage eventually resulting in a crash (commonly referred to as Memory Leaks).

A useful way of ensuring that managed resources are correctly cleaned up in a timely manner is to implement the IDisposable interface (and actually use it within a using block) on your objects.  Make sure you understand how this works how to implement it.


private Boolean disposed;

protected virtual void Dispose(Boolean disposing)
    if (disposed)

    if (disposing)
        //TODO: Managed cleanup code here, while managed refs still valid
    //TODO: Unmanaged cleanup code here

    disposed = true;

public void Dispose()


Code snippet taken from SideWaffle.  Its not enough to simply implement IDisposable, you have to take it a step further by adding a second Dispose method to ensure that both managed and unmanaged resources are properly disposed.

Useful resources:

Three Common Causes of Memory Leaks in Managed Applications (DavidKlineMS)

Garbage Collector Basics and Performance Hints (MSDN)

Writing High-Performance .NET Code (Ben Watson)

Explain why you might use MVC over WebForms?

Another curve ball that employers might throw at you is “Why might you decide to use ASP .NET MVC over something like WebForms”.  I stuttered for a good 30 seconds before I eventually came up with a decent answer to this one, because simply saying “because MVC is better” is not a good enough argument.

Here are some things that come to mind;

  • MVC generates much simpler HTML code, which will be easier to style and maintain over time.
  • MVC arguably has a smaller learning curve, because Razor is very intuitive and developers get to reuse their existing knowledge of HTML/CSS without having to learn how specific user controls work.
  • Due to MVC’s simplified page lifecycle, overhead on the server is reduced potentially resulting in better performance.

There is endless argument about this on the web (the only example you need). I think in reality the employer is trying to establish two things here;

  • How well do you know your frameworks
  • But more importantly, can you assess the benefits and drawbacks of different frameworks and make an informed, unbiased decision regarding which one to use.  I.e. don’t just use it because everybody else is.

No-SQL databases

If you think that SQL server is the be-all-and-end-all, then its time to wake up! Its the year 2014 and the tech world has moved on.  I’m not suggesting for a second that companies are abandoning SQL Server, I believe that it will continue to play a major role in our industry for at least the next 5 years.  However, No-SQL databases are gaining massive traction because of their general speed, ease of use, and scalability benefits (not to mention the fact that SQL Server is very expensive, whereas RavenDB and MongoDB are much more affordable).

I’d recommend that you look at, and understand, each of the following;

Boxing and Un-boxing

It simply amazes me just how many developers don’t understand boxing and un-boxing.  Granted, its been less of an issue since generics was introduced in .NET 2.0 but done wrong, your application’s performance and memory usage will be seriously affected. 

Useful resources:

Also note, when a prospective employer asks you to explain this problem, they may also ask you to explain the difference between reference types and value types.  Reference types of course are classes, whereas value types are structs.  A value type can be thought of as the actual value of an object, whereas a reference type typically contains the address of the actual value, or null (value types are not nullable).

Hoisting and Closures

Developers now are required to have a broader range of skills than has typically been the case.  Its usually not enough to have just SQL and C# on your CV, employers are increasingly looking for more well rounded developers, with a range of skills including (but not limited to); HTML, CSS, JavaScript, KnockoutJS, TDD, AngularJS and so on.

You may never have realised it, but when writing JavaScript code variable scope is not exactly black and white.

Take the following example (pinched and adapted from here)


    x = 5; 

    var x;


What is the value of x? No tricks here, the answer is of course 5, but why does this work?  Because the variable declaration is pulled (hoisted) to the top of the current scope.  So regardless of where you declare your variables inside a function, they will always be hoisted to the top.  Be sure that you understand this, as its a basic concept but often misunderstood.

Similarly, closures are another confusing concept of JavaScript that you may be asked about.  In the simplest terms, when you have a function inside another function, the inner function has access to any declared variables in the outer function. 



    var x = "Hello";

    var f = function(){
        alert(x + ", World!");



What is the result? Hello, World! of course, again no tricks.  The code in the inner function always has access to variables declared in the outer function.

That explanation should pass the Albert Einstein test.

If you can’t explain it to a six year old, you don’t understand it yourself.

Is a string a reference type or a value type?

The one I used to dread the most, until I learnt it properly and understood it.  A string is a reference type, but it behaves like a value type!  Unlike most other reference types, a string is immutable, meaning that the object itself cannot be changed.  When you call a method such as Remove or Substring, you are creating a copy of the string with the new value.  The original string remains intact until it is de-referenced.

The primary reason for this is because the size of strings means that they are too big to be allocated on the stack.

As a side note, take the following code;

string c = "hello";
string d = "hello";

Console.WriteLine(c == d);

Why is the result true?  Well this is a .NET optimization to reduce the memory footprint.  Under the hood each variable has the same pointer (0x021x15ec in this case) to the actual value.  You should always use String.Equals when comparing strings to ensure that the actual value of each string is equality checked, instead of the pointer.


We looked at 8 concepts that every decent .NET developer should understand, especially when interview for a new role.  Whilst these may seem like simple concepts, they are often misunderstood and this will quickly be picked up by even the most inexperienced interviewer.  It’s important for .NET developers to know their language and their tools inside out to ensure that they have every chance of landing that next dream job.

How to add SignalR to the telephone directory sample application

As part of a recent mini series we created a very simple telephone directory web page that showed some features of Bootstrap, KnockoutJS, jQuery, Web API and the Entity Framework.  Just for fun, I figured it would be cool to add SignalR so that we could see how simple it is to add full duplex, real time communications to your website.

The first parts of the mini series can be found here;

github4848 This post is a continuation of the original project.  You can find the entire source code over on GitHub.


Add SignalR using NuGet

At the time of writing, you have to be a little careful when installing the SignalR NuGet package.  We’ll install and setup SignalR the way it is supposed to be done, and then we will fix a problem that we encounter at the end.

First, open the Telephone Directory project, and install SignalR using the Package Manager Console;

install-package Microsoft.AspNet.SignalR

SignalR has a dependency on Microsoft.Owin, which will be installed automatically for you. 

Add a new item to your project using the OWIN Startup Class template, call the file Startup.cs and add the following code;

using Microsoft.Owin;
[assembly: OwinStartup(typeof(TelephoneDirectory.Startup))]

namespace TelephoneDirectory
    using Owin;
    public class Startup
        public void Configuration(IAppBuilder app)

At this point you should be able to run your application.  Granted, not much (other than the standard functionality) should happen.  However, if you try this now you will receive the following error message;

An exception of type ‘System.IO.FileLoadException’ occurred in Microsoft.AspNet.SignalR.Core.dll but was not handled in user code
Additional information: Could not load file or assembly ‘Microsoft.Owin, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

This is because the dependency resolver has brought down the wrong version of Microsoft.Owin.Security.  To fix the problem, run the following command in the Package Manager Console;

install-package Microsoft.Owin.Security -Version 2.1.0

If you run the application again, the problem should be resolved.

Create a Hub

This tutorial assumes that you have at least a little bit of knowledge about how SignalR works.  All you basically need to do is create a new class that inherits from Microsoft.AspNet.SignalR.Hub, and any methods you add to your hub will be accessible from your JavaScript code.

There are two methods we need to add, one to tell other connected clients that an entry (an entity) has been added or updated, and another to notify that an entity has been deleted.

Create a new Hub called EntryHub (I created a new folder called Hubs) and add the following methods;

public class EntryHub : Hub
    public void AddOrUpdate(TelephoneEntry telephoneEntry)

<pre><code>public void Delete(TelephoneEntry telephoneEntry)



Add SignalR to your client JavaScript

You reference SignalR by adding the following scripts to your page (or bundle);

<script src="Scripts/jquery.signalR-2.0.2.min.js"></script>
<script src="signalr/hubs"></script>

Ensure that these scripts are positioned before index.js, so we avoid any issues going forward.

Open up index.js, and grab a reference to the hub you created earlier as follows (add this into the TelephoneViewModel underneath your existing properties);

var hub = $.connection.entryHub;

We are referencing the hub as a variable because we only want it to be accessible to our view model (not the view as we want to maintain separation of concerns).

Now at the end of the view model, just before we call load, open a connection to the server;


You’re now ready to being sending and receiving data.

Send data to the server

To send data to the server, you simply need to call the hub method you created earlier.  Update the post method as follows; = function (telephoneEntry) {
    $.post('/api/Data/', telephoneEntry, function (id) { = id;

<pre><code>    hub.server.addOrUpdate(telephoneEntry);


When we create a new entity and after it has been saved by the Web API, we send it to our SignalR hub to tell other connected clients that an entity has been added.

Receive data from the server

Receiving data from the server is equally simplistic.  You use the method signature of the method you added to your hub.  Add the following;

hub.client.addOrUpdate = function(telephoneEntry) {};

SignalR will invoke this method every time the corresponding server method is invoked.  Flesh out the method as follows;

hub.client.addOrUpdate = function (telephoneEntry) {

<pre><code>var result = $.grep(self.telephoneEntries(), function (entry) {
    return ==;

if (result.length == 0) {
} else {
    self.telephoneEntries.replace(result[0], telephoneEntry);


As we have a single method for adding and updating, we need to determine which action we need to take.  I have used the jQuery grep method to search the telephoneEntries array looking for a matching ID.  If there are no matches, we add the entity and if there are matches we update the existing entity.

Add the following code to respond to the delete method;

hub.client.delete = function (id) {
    var result = $.grep(self.telephoneEntries(), function (entry) {
        return == id;

<pre><code>if (result.length &amp;gt; 0)


The hub method passes us just the entity Id to reduce bandwidth.

Run the program now, try adding an entity.  You will encounter an error;

Uncaught ReferenceError: Unable to process binding “text: function (){return number }” Message: number is not defined

One more thing… camelCase

Generally, and I believe this is a best practice, JavaScript variables/properties are camel cased (camelCase).  Normally, C# properties are title cased (TitleCase).  So when SignalR does its magic and sends your entity from the server to the client, your entities property names are in title case, so your JavaScript won’t quite match up.

One way to fix this issue in to use the JsonProperty attribute, which is used to specify the name to give the property when serialization takes place.  Update the TelephoneEntry entity as follows;

public class TelephoneEntry
    public string FirstName { get; set; }

public int Id { get; set; }

public string LastName { get; set; }

public string Number { get; set; }


Hopefully everything should now be working as expected.


SignalR is a fantastically powerful, lightweight library that gives us full duplex, real time communication in a multi-client environment.  You can use NuGet to install SignalR, create a hub with your methods to be exposed to the clients, and consume those methods in a simple manner.  There are a couple of quirks you have to workaround (hopefully these will be resolved in future releases), but basically you can get it up and running in minutes, adding a new layer of interactivity to your website.