Constructor Functions and Controllers in AngularJS

Wednesday, November 12, 2014 by K. Scott Allen
5 comments

AngularJSThere are a few points in “AngularJS: The Bad Parts” I’d be happy to debate, but let’s focus on “Bad Idea #4”, talking about controller constructor functions:

That’s right, these constructors never create new instances. They are “applied” to a scope object.

Let’s use the following example. A simple controller that is setup to use controller as syntax from the view.

var module = angular.module("app", []);

var MainController = function() {
      
    this.message = "Hello";
    
    this.changeMessage = function() {
        this.message = "Bonjour!";
    };

    this.isMainController = function(object) {
        return object instanceof MainController;
    };

    this.isObject = function(object) {
        return object instanceof Object;
    };

};

module.controller("MainController", MainController);

If we place the following markup in a view:

<div>
    {{ main.isMainController(main) }}
    {{ main.isObject(main) }}
</div>

.. we’ll see the output true and true. The first true is a good indication that Angular does use the controller function as a constructor function, in other words, Angular invokes the function using the new keyword. In fact, we can even rewrite a controller using the everyday constructor function and prototype object approach of JavaScript, and everything just works.

var MainController = function() {
    this.message = "Hello";         
};

MainController.prototype = {
       
   changeMessage: function() {
       this.message = "Bonjour!";
   },

   isMainController: function(object) {
       return object instanceof MainController;
   },

   isObject: function(object) {
       return object instanceof Object;
   }

};

The above is actually a good example of why I like working with Angular. You can write plain, simple JavaScript objects using established conventions and terminology, then plug the objects into Angular to achieve a goal. There is no magic required or intrusions from the framework. You can even start writing controllers using ES 6 class syntax, but that’s a topic for a future post.

Features of ES6 Part 10: Behind The Class

Tuesday, November 11, 2014 by K. Scott Allen
1 comment

In a previous post we looked at the new class keyword in JavaScript.

We’ve always had the ability to create objects in JavaScript, and give these objects data to hold and methods to call. In fact, we could have written an “employee” object using a simple object literal instead of a class.

let developer = { 
    name: "Scott", 
    doWork: function() { 
        return `${this._name} is working`; 
    }, 

    get name() { 
        return this._name.toUpperCase(); 
    }, 

    set name(newName) { 
        if(newName) { 
            this._name = newName; 
        } 
    } 

}; 

expect(developer.name).toBe("SCOTT"); 

developer.name = "Alex"; 
expect(developer.doWork()).toBe("Alex is working");

The advantage to having a class is how we can create multiple developers just by using the new keyword and not have to write out an entire literal definition like the above code. Each object is unique and contains its own data, but the method implementations are consistent and shared.

let dev1 = new Employee("Scott"); 
let dev2 = new Employee("Alex");

In fact, even before the class keyword came along, we had the ability to define a blueprint for object construction in JavaScript. The approach was one we called the “constructor function and prototype object” approach.

let Employee = function(name) { 
    this._name = name; 
}; 

Employee.prototype = { 

    doWork: function() { 
        return `${this._name} is working`; 
    }, 

    get name() { 
        return this._name.toUpperCase(); 
    }, 

    set name(newName) { 
        if(newName) { 
            this._name = newName; 
        } 
    } 
}; 

let developer = new Employee("Scott"); 
expect(developer.name).toBe("SCOTT");

As it turns out, all the class keyword is doing behind the scenes is setting up a constructor function and prototype object. This means all of the tricks we’ve learned in the past still work. For example, “borrowing” a method from a prototype object:

class A { 

    doWork() { 
        return "complete!"; 
    } 

} 

var result = A.prototype.doWork.call(); 
expect(result).toBe("complete!");

The instanceof operator also works as expected.

class A { 
    // … 
} 

var a = new A(); 

expect(a instanceof A).toBe(true); 
expect(a instanceof Object).toBe(true);

You can also still augment all instances of a type by modifying prototype objects (if you like to live dangerously).

class A { 

} 

A.prototype.newMethod = function() { 
    return "new!"; 
}; 

var a = new A(); 
expect(a.newMethod()).toBe("new!");

You can think of the class keyword as being syntactic sugar for creating constructor functions and prototype objects. However, there is more to the class keyword than what we’ve seen so far. We’ll look at class inheritance in the next post.

Working with Validators and Messages in AngularJS

Thursday, October 16, 2014 by K. Scott Allen
7 comments

In a previous post we looked at a custom validation directive to confirm a user’s password.

The bigger picture from the post was not about how to register a user for a website, but how to work with the new validation and validation message features introduced in Angular 1.3, which just fully released this week.

Before we take a step back and look in more detail at what’s new in 1.3, let’s review what stays the same when it comes to form validation.

Same Old Validation

Here are a few points about what has not changed with validation.

1. When you give a <form> a name, Angular will add a property with the same name to the current $scope.

2. All named inputs inside a named <form> will be added to the form’s named property in $scope.

3. Each form and input still have boolean properties to describe if the object is $pristine or $dirty, and $valid or $invalid.

4. Angular still adds CSS classes to each form and input describing the state of the object (ng-dirty, ng-pristine, ng-valid, ng-invalid).

5. There is still an $error property on each form and input. The $error property describes failed validations.

Thanks to the behavior described in the above points, you can have a relatively functional form just using the following markup:

<form name="profileForm"
      ng-submit="profile.submit(profileForm.$valid)"
      novalidate>
      
    <input type="number" name="favoriteNumber" 
           ng-model="profile.number"
           required min="1" />
      
    <input type="submit" value="Save" />
      
</form>

.. and a little bit of CSS ..

.ng-invalid {
  border-color: red;
  border-width: 2px;
}

You can try the above code on Plunker.

The Emperor's  New Validations

emporer Angular 1.3 introduces a number of new features for form validation, including a new approach to writing validation code, a new approach to showing validation error messages, and plenty of small enhancements. like adding ng-submitted as a class to a form after a submit event. To only show validation errors or color code erroneous inputs after the user presses the submit button now only requires a more specific selector in CSS.

form.ng-submitted .ng-invalid {
  border-color: red;
  border-width: 2px;
} 

Try the updated plunk here.

What follows is some more detail about validation messages and the validation API.

ngMessages

One of the messier parts of forms with Angular was the display management of validation errors. The management usually involved ng-if or ng-show directives with ugly expressions like in the following code.

<input type="number" name="favoriteNumber" 
       ng-model="profile.number"
       required min="1" />

<span ng-if="profileForm.favoriteNumber.$error.required">
    Required!
</span>

And this is only a single validation error for a single field. Once you added messages for each validation attribute in each input field, then added class names, there was quite a bit of markup.

ngMessages is a new module for Angular that your application can depend on after adding angular-message.js. Once in place, validation messages look like the following.

<input type="number" name="favoriteNumber" 
       ng-model="profile.number"
       required min="1" /> 
<div ng-messages="profileForm.favoriteNumber.$error" class="errors">
    <span ng-message="required">Required!</span>
    <span ng-message="min">Too small!</span>
</div>

The ngMessages directive will watch the $error property of an input and toggle the first matching ngMessage directive in its messages collection.

Now we’ve gotten most of the uglier expressions out of the markup, but we can also define a template file for messages..

<span ng-message="required">Required!</span>
<span ng-message="min">Too small!</span>
<span ng-message="number">Must be a number!</span>
<span ng-message="odd">Odd numbers only!</span>
<!--  and so on, for all possible validation attributes -->

.. and include the template whenever we need to show error messages for a field.

<div ng-messages="profileForm.favoriteNumber.$error" 
     ng-messages-include="messages.html"
     class="errors">
</div>

Now we’ve removed most of the unsightly and bulky markup from our forms. However, since error messages come from a template they are likely to be generic error messages like the ones in this example, messages like “Too small!”. There is no easy way to poke a field name or attribute value into a message, unfortunately, but there is the ability to override a message.

<div ng-messages="profileForm.favoriteNumber.$error" 
     ng-messages-include="messages.html"
     class="errors">
           
     <!-- overrides the min message from the include -->
     <span ng-message="min">Must be more than 1</span>
</div>

This last bit of code added to the Plunker here.

$validators

Also new in 1.3 is the $validators object on the ngModel controller. Adding a property to this object effectively registers a new validation rule to an input using the name of the property. To get to the $validators property you’ll want to create a custom directive that requires the ngModel controller. The following code adds an “odd” validation rule that I can use to ensure that an input type=”number” will only accept odd numbers.

app.directive("odd", function() {
    return {
        restrict: "A",
        
        require: "ngModel",
        
        link: function(scope, element, attributes, ngModel) {
            ngModel.$validators.odd = function(modelValue) {  
                return modelValue % 2 === 1;
            }
        }
    };
});

Angular automatically invokes the odd function whenever the model value changes (you can also receive the view value as a second parameter)., All the validation function needs to do is return true or false – is the value valid? A return of false will mark the model as invalid and set a property on the associated $error object. To apply the validation rule use the directive on an element using ngModel. 

<input type="number" name="favoriteNumber" 
       ng-model="profile.number"
       required min="1" odd /> 

The associated ngMessage for the attribute will automatically appear when the validation rule fails.

<span ng-message="odd">Odd numbers only!</span>

An updated plunk using the above code lives here.

$asyncValidators

A validation rule added to a model’s $asyncValidator pipeline will typically be a validation rule that needs server-side logic to make a decision. Like everything and anything async in Angular, an async validator will return a promise. If the promise resolves, Angular considers the value valid. If the promise is rejected, the value is invalid.

Here is a prime number validation rule that simulates a slow server-side response using $timeout.

app.directive("prime", function($q, $timeout) {

    var isPrime = function(n) {
      if (n < 2) { 
        return false; 
      }

      for (var i = 2; i <= Math.sqrt(n); i++) {
        if (n % i == 0) {
          return false;
        }
      }
      return true;
    };

    return {
      restrict: "A",
      require: "ngModel",
      link: function(scope, element, attributes, ngModel) {
        ngModel.$asyncValidators.prime = function(modelValue) {
          var defer = $q.defer();
          $timeout(function(){
            if(isPrime(modelValue)) {
              defer.resolve();
            } else {
              defer.reject();
            }
          }, 2000);
          return defer.promise;
        }
      }
   };
});

Using an async validator is no more difficult than using a regular validator, all we need to do is add the directive to the input element.

<input type="number" name="favoriteNumber" 
       ng-model="profile.number"
       required min="1" odd prime /> 
      
<div ng-if="profileForm.favoriteNumber.$pending">
     Calculating....
</div>

Notice you can give some visual clues a pending validation calculation by using the $pending flag provided by Angular.

Try this version of the code in this plunk.

Summary

The summary for this article is intentionally left blank. Like you were going to read it anyway…

Features of ES6 Part 9: Classes

Tuesday, October 14, 2014 by K. Scott Allen
8 comments

Historically, many developers learn JavaScript after learning languages like C++, Java, C#, Ruby, or Python. All of these languages have a class keyword, and in many of these languages, the class keyword is the primary building block for constructing software.

In modern times, many developers learn JavaScript as a first language, so the new class keyword in ES6 will be a brand new tool.

Regardless of a developer’s background, the class keyword in JavaScript will play a role similar to the class keyword in other languages. Classes allow developers to define a blueprint for constructing objects. Each object a program creates from the class blueprint will be an object with the same methods and placeholders for data specific to each object.

We’ve always had the capability of building object with data and behavior in JavaScript, but like other ES6 features, the class keyword makes the common practice both succinct and more explicit.

The Keyword

Every class has a name, and a body containing the method definitions for the class.

class Employee {

    hire() {
        this.hired = true;
    }

    getStatus() {
        if(this.hired) {
            return "hired";
        }
    }
}

The above class has two methods: hire and getStatus. Notice we do not need to use the function keyword to define the methods. These methods will be available on every object we create using Employee, and as you can see in the implementation, these methods can save and retrieve state inside the object using the this keyword.

We create Employee objects using the new keyword.

let developer = new Employee();
developer.hire();

expect(developer.hired).toBe(true);
expect(developer.getStatus()).toBe("hired");

Quite often you’ll want an object to initialize itself with specific data right from the start. We can add this initialization logic using a constructor.

Class Constructor and Properties

Every class may specify a constructor. The runtime will invoke the constructor when instantiating a class, and we can use the constructor to initialize state in an object, often by accepting parameters in the constructor method.

class Employee {

    constructor(name) {
        this.name = name;
    }

    getName() {
        return this.name.toUpperCase();
    }
}

let developer = new Employee("Scott");
expect(developer.name).toBe("Scott");
expect(developer.getName()).toBe("SCOTT");

A class can also define a property with get and set to encapsulate a field.

class Employee {

    constructor(name) {
        this._name = name;
    }

    doWork() {
        return `${this._name} is working`;
    }

    get name() {
        return this._name.toUpperCase();
    }

    set name(newName){
        if(newName){ 
            this._name = newName;
        }
    }
}

let developer = new Employee("Scott");
expect(developer.name).toBe("SCOTT");

developer.name = "Alex";
expect(developer.doWork()).toBe("Alex is working");

ES6 also supports class inheritance and  interaction between a class and the class superclass. We’ll take a look at these features in the next installment of the series.

Confirm Password Validation in AngularJS

Monday, October 13, 2014 by K. Scott Allen
3 comments

AngularJSForm validation and custom validation directives are relatively easy with the changes in Angular 1.3. Try the sample plunk here.

Let’s look at the scenario where we need to confirm a new user’s password during registration. Registration is not so common in this day and age of federated identity, but is still a useful example and a frequent requirement.

Custom compareTo directive in AngularJS

A Custom Directive

We could put logic into a model to confirm a password, but it is probably better to separate the logic into a reusable directive. AngularJS already provides directives for the standard HTML validation attributes like required. All we need to do is follow a similar pattern.

1. Require the ngModel controller.

2. Add a method to the ngModel controller’s $validators object. Angular will invoke the function when the model value changes. The function returns a boolean, and a return value of false will set the corresponding ngModel’s $error property automatically.

The compare-to directive looks like the following:

var compareTo = function() {
    return {
        require: "ngModel",
        scope: {
            otherModelValue: "=compareTo"
        },
        link: function(scope, element, attributes, ngModel) {
            
            ngModel.$validators.compareTo = function(modelValue) {
                return modelValue == scope.otherModelValue;
            };

            scope.$watch("otherModelValue", function() {
                ngModel.$validate();
            });
        }
    };
};

module.directive("compareTo", compareTo);

You can use the directive inside of markup like so:

<input type="password" name="confirmPassword"  
        ng-model="registration.user.confirmPassword" 
        required 
        compare-to="registration.user.password" />
            
<div ng-messages="registrationForm.confirmPassword.$error" 
      ng-messages-include="messages.html"></div>

The ng-messages directives, also new in 1.3, makes it easy to provide common error messages for form inputs. You can also see them at work in the plunk.

Features of ES6 Part 8: Tagged Templates

Tuesday, September 30, 2014 by K. Scott Allen
2 comments

In a previous post we looked at template literals.

You might have glanced at the code in that post and thought: “gee, that’s useful”. Or, perhaps you are more the skeptical, security conscious type who thought “gee, new and easy ways to create injection vulnerabilities”.

Regardless of your initial take, an even more powerful feature in ES6 is the tagged template literal.

The tag is a function with the ability to interpret and process a template. The tag appears in front of the template, so in the following code the tag is upper.

var result = upper `${x} + ${y} is ${x+y}`;

The runtime will invoke the tag function and pass as a first argument an array containing the individual pieces of literal text from the template.

let test = function(literals, ...values) {
    expect(literals.length).toBe(2);
    expect(literals[0]).toBe("Hello, ");
    expect(literals[1]).toBe("!");
    return "test";
};

let name = "Scott";
let result = test `Hello, ${name}!`;
expect(result).toBe("test");

The template in the above code, `Hello, ${name}!`, generates an array of two values. The values contain only the literal text and no placeholders. The runtime will pass the evaluated expressions from any placeholders as individual arguments after the first array argument. It will be a common practice to capture the values using a rest parameter. Here is another code snippet showing all of the literals and values passed to the tag function.

let test = function(literals, ...values) {
    expect(literals.length).toBe(3);
    expect(literals[0]).toBe("Hello, ");
    expect(literals[1]).toBe(", ");
    expect(literals[2]).toBe("!");
    
    expect(values.length).toBe(2);
    expect(values[0]).toBe("Allen");
    expect(values[1]).toBe("Scott");
    
    return "test";
};

let firstName = "Scott";
let lastName = "Allen";
let result = test `Hello, ${lastName}, ${firstName}!`;

expect(result).toBe("test");

The general idea is that a tag function can build the result of a tagged template by concatenating strings. For each literal value, append the literal to the result and then append a value. However, a tag can interpret a template using any logic it desires, so if the tag simply wants to heedlessly return the string “test” regardless of the contents of the template, it can (as the code above is doing).

A more reasonable implementation of a tag might look like the following.

let upper = function(strings, ...values){
    let result = "";

    for(let i = 0; i < strings.length; i++){
        result += strings[i];
        if(i < values.length){
            result += values[i];
        }
    }

    return result.toUpperCase();
};

var x = 1;
var y = 3;
var result = upper `${x} + ${y} is ${x+y}`;

expect(result).toBe("1 + 3 IS 4");

The tag upper builds a result that would look just like the normal evaluation of the template literal, but uses toUpperCase before returning the result to ensure the result uses all uppercase letters.

The Significance of Tagged Template Literals

A tag’s ability to modify the output of a template is powerful. Imagine a tag that can build safe URLs by URL encoding a result, or a safehtml tag to build encoded HTML. Since JavaScript is often used to generate content (HTML, JSON, URLs, form encoded inputs, etc), a tag library that makes content generation safe and easy will be invaluable.

Even more interesting is the idea that the content inside of a template could be a language unto itself. The tag function could be the gateway to the interpreter for a domain specific language, which opens up many possibilities for the use (and abuse) of tagged template literals.

Want more? Watch JavaScript Fundamentals for ES6 on Pluralsight!

Features Of ES6 Part 7: Template Literals

Thursday, September 18, 2014 by K. Scott Allen
2 comments

Template literals provide JavaScript with some basic string formatting capabilities. Just like many template technologies, template literals in JavaScript consist of literal text, and placeholders where the runtime can evaluate an expression to poke data into the text.

let name = "Scott";
let message = `Hello, ${name}!`;

expect(message).toBe("Hello, Scott!");

Backtick characters (`) enclose the entire template literal, while $ and {} denote the substitutions. Inside a substitution, you can use identifiers and expressions.

let showTheMath = function(x,y ){
    return `${x} + ${y} is ${x + y}`;
};

let result = showTheMath(3,4);

expect(result).toBe("3 + 4 is 7");

Template literals can even span multiple lines.

let message = `This is
               a short, but multi-line message`;

Note that message will contain a newline character because newlines (and trailing spaces) are significant inside of a template literal.

Template literals are a useful addition to the language. However, template literals become exceptionally interesting when using them with a tag. We’ll look at tagged template literals next week.

Want more? Watch JavaScript Fundamentals for ES6 on Pluralsight!

by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!