December 2015

Angular 2 Property Binding Syntax

In my last post I went through the event binding syntax in Angular 2. This post details property binding syntax …

Property binding is where data flows from the component’s model into the component’s template to set a DOM property or an angular directive. The basic syntax for property binding is …

… where propertyName is a DOM property name or a directive name and an expression is an angular template expression. An angular template expression is just a JavaScript expression with a few exceptions.

In the example below, the agree checkbox is disabled until a name > 2 characters is entered. The name text box is green when > 2 characters and otherwise red. The submit button is disabled until the agree checkbox is ticked.

There are better ways to acheive this behaviour but the example demonstrates property binding in angular 2.

  • On line 8, validateName() is called as the user enters a name which in tern sets properties validName and nameClass on lines 29 to 37
  • Also on line 8, the ngClass directive is bound to the nameClass property
  • On line 9, the checkbox’s disabled property is bound to the opposite of the validName property
  • Also on line 9, setAgreed() is called when the checkbox is checked / unchecked which in tern sets the agreed property on line 39
  • On line 10, the submit button’s disabled property is bound to the opposite of the agreed property

Recommended reading for building great angular apps:

Connect with me:RSSGitHubTwitterLinkedIn

Angular 2 Event Binding Syntax

Angular 2’s binding syntax is a little strange at first but after a while it does make sense when you get familar with all the different types of bindings.

The basic syntax for event binding is …

… where eventName is a native DOM event and functionToCall is a function in the component’s class. You can pass the native event argument in using $event.

Below is an example of a search input component …

Some key points …

  • On line 6 we bind to the keypress event on the textbox calling the preventNumbers() function. We pass in the native event argument using $event
  • On line 6 we also use a local variable, #criteria, so that we can reference the textbox in the button’s binding on line 7
  • On line 7 we bind to the click event on the button calling the search() function passing in the value of the search textbox.

Recommended reading for building great angular apps:

Connect with me:RSSGitHubTwitterLinkedIn

Angular 2 Directive Case?

I have been (and still a bit) confused about the case of angular 2’s directives … is it *ngFor or *ng-for … ie camel case or dash case?
I’ve always used dash case in the alpha’s of Angular 2. However, the docs suggests camel case … but then the working example in this doc suggests dash case …


I decided to do a test rig myself on the latest version of Angular 2 (beta 0) …


The following component works fine:


However, the following component errors:

You get: Template parse errors: Can’t bind to ‘ng-forOf’ since it isn’t a known native property

So, it looks like we’re using camel case now in Angular 2 beta but the live examples still need to catch up …

Recommended reading for building great angular apps:

Connect with me:RSSGitHubTwitterLinkedIn

Angular 2 Form Validation

In the last post I introduced angular 2’s model driven form approach. In this post I’m going to go through how to implement validation rules on a model driven form …

Standard validators

At the moment there seem to be 3 standard validators which pretty much do what they say on the tin:

  • Validators.required
  • Validators.minLength
  • Validators.maxLength

Here’s some component code that references the standard required and minLength validators:

Multiple validators

You can use Validators.compose to specify multiple validators for a field:

Custom validation

You can reference and implement custom validation as in the following example:

Some keypoints:

  • The validation function takes in the field Control as a parameter
  • Control.value gives the value of the field
  • The function should return null if the field is valid
  • The function should return an object if the field is invalid. This object is referenced in ControlGroup.errors when the form is in an invalid state

ControlGroup validation properties

There are some useful properties on ControlGroup (loginForm in the above examples) that can be used in validation code:

  • ControlGroup.valid is a boolean that tells us whether the form is in a valid state
  • ControlGroup.errors is null when the form is in a valid state. When the form is in an invalid state it returns an object of invalid controls
  • ControlGroup.value gives the field values

One thing I haven’t worked how to do yet is async validation …

Recommended reading for building great angular apps:

Connect with me:RSSGitHubTwitterLinkedIn

Angular 2 Model Driven Forms

Model driven forms is a new concept in angular 2. In angular 1, all we had was template driven forms which by the way, you can still use in Angular 2.

What is a model driven form?

Before we look at why you would want to use model driven forms, what do we mean by model driven forms?

Architecturally, a form has 4 parts:

  • DOM. This is where the form is rendered to!
  • Template. This defines how the fields are laid out in the DOM
  • Form Model. This defines the fields on the form and some of the associated UI logic such as what the client side validation rules are and what the default values are
  • Domain Model. This contains the fields and their values

In angular 1, the form model was hidden from us – angular creates this for us from the template. In angular 2 we can create the form model using FormBuilder. Using FormBuilder in Angular 2 is taking the model driven approach.


So, why would we want to do this? This sounds like extra work – if angular 1 did this for us, why would we now want to write that code? There are a number of reasons …

  • Maintainability. When fields on the form depend on conditions, when the validation for fields depend on conditions or the defaults depend on conditions, it may be easier to read and debug imperative code for this rather than declarative code in the template
  • More unit testable. More of the UI logic can now be abstracted and totally independent of the DOM, which makes unit testing easier
  • Performance. In angular 1, angular managed the data flow via 2 way bindings which can be slow if you have lots of bindings with large dependency chains. In the model driven approach you can control the flow of data
  • Functional Reactive Programming. Controlling the data flow means that you can use functional reactive programming for UI logic.

So, in general, when we are dealing with large complex forms, the model driven approach may be a better approach.


Let’s look at a simple login form as an example.
This is an angular 2 login component …

Here are some key points …

  • [ng-form-model]= on the form tag on line 11 defines the name of our form model. We can reference this in order to extract values from the form – see the comments on lines 37 and 38.
  • ng-control= on the input tags defines the name of the fields in our form model. These names match the field names passed into the form builder on lines 30 and 31 and also how you could extract form values on lines 37 and 38
  • FormBuilder is passed into the constructor on line 27 and then associated with the form model on line 29. Lines 30 and 31 define the fields in the model – the first element in the array is the default value and the second element is the validation rule

This example is hardly a large complex form but it demonstrates the concepts. What do you think of model driven forms?

Recommended reading for building great angular apps:

Angular 2 Drop Down Binding

Binding to drop downs is always interesting. Here’s an example in Angular 2 …


Let’s look at the template first in our component.

  • On line 5, we use a NgFor to list the drop down options, looping over a products array in our model and making use of a product local variable.
  • We use a property binding to bind the drop down option value to the product id.
  • We use interpolation to bind the drop down option text to the product name
  • On line 4, we use an event binding to handle setting the selected product when the drop down selection changes
  • On line 7, we use interpolation again to output the selected product name


Let’s look at the code now …

Firstly we need a class to define a product …

We can now define the class for our drop down component …

  • On line 2, we’ve hardcoded an array of products for this demo
  • On line 7, we have a property selectedProduct to hold the selected product which is initialised to the first product
  • On line 8, we have an onSelect method which handles when a drop down option is selected which in tern sets the selectedProduct property

Is there a simpler way of handling the selected product? Is there a directive that could replace the onSelect() method in the component code?

Recommended reading for building great angular apps:

Angular 2 Template Looping Syntax

Assuming we have a products array as follows …

… we could output these products using the following looping syntax in Angular 1 …

This is similar In Angular 2 …

So, simular-ish syntax. The key differences are …

  • We now use the NgFor directive
  • Rather than dealing with $scope, we now set local variables using the # prefix

Recommended reading for building great angular apps:

Here’s more info

Connect with me:RSSGitHubTwitterLinkedIn

JavaScript Multi-line Strings

Traditionally I’ve always used something like the following when writing multi-line strings …

In ES6 you can write multi-line strings much cleaner using backticks rather than single or double quotes …

… which is much cleaner!

A backtick is a diagonal single quote which is at the top left of my keyboard.

The latest versions of Chrome, Firefox, Edge and Safari all support this. Unfortunately IE doesn’t.

Connect with me:RSSGitHubTwitterLinkedIn