Arrow Function In ES6

Tuesday, December 9, 2014 by K. Scott Allen
5 comments

JavaScript has always been a functional programming language. You can pass functions as arguments to other functions, and invoke a function that returns a function back to you. The ES6 standard improves JavaScript’s functional programming capabilities by offering a new, succinct syntax for creating functions. In addition, ES6 defines new syntax to offer features closely associated with functional programming, features like iterators and lazy evaluation. Let’s start looking at the new capabilities by looking at the arrow function, which will look familiar to anyone who has worked with CoffeeScript or C# code.

An arrow function doesn’t require the function keyword, or curly braces, or a return statement. However, arrow functions do require a new operator, the =>, which looks like an arrow pointing to the right and which gives these expressions their name. To build an arrow function for adding two numbers, one simply has to write the following.

let add = (x,y) => x + y; 

On the left-hand side of the arrow is the parameter list for the function. In this example there are two parameters, x and y. To the right of the arrow is the executable code. In this case, the code returns the sum of x and y. You could think of the arrow as pointing the parameters to the code that uses them.

Invoking an arrow function looks no different than invoking a traditional function.

let result = add(3, 5); 

expect(result).toBe(8);

Arrow functions that use exactly one function parameter do not need to surround the parameter with parenthesis.

let square = x => x * x; 

If an arrow function requires zero parameters, or more than one parameter, then the parenthesis are required.

let add = (x,y) => x + y;             // required parens 
let square = x => x * x;              // optional parens 
let compute = () => square(add(5,3)); // required parens 
let result = compute(); 

expect(result).toBe(64); 

So far, the examples use a single expression to the right of the arrow operator. When using a single expression, curly braces and return statements are not required. The return value of the function will be the value of the expression.

However, an arrow function may contain a more complex block of statements, but this approach does require braces and an explicit return (if the function wants to return a value).

let add = (x,y) => {
    var result = x + y;
    return result;
};

In the next post of this series, we’ll look at a special quality of arrow functions, and also see how we can use them in some common scenarios.

Class Inheritance in ECMAScript 6

Tuesday, November 25, 2014 by K. Scott Allen
4 comments

Continuing from a previous post

Over the years, there have been various approaches to building class hierarchies in JavaScript. All these approaches worked by stitching together constructor functions and prototype objects and each approach was slightly different from the others.

The ES6 standard allows for a declarative, consistent approach to inheritance using the class and extends keywords. As an example, let’s start with a simple class to represent a person with a name.

class Person {
    
    get name() {
        return this._name;
    } 

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

}

var p1 = new Person();
p1.name = "Scott";
expect(p1.name).toBe("Scott");

Now we also need a class to represent an employee who has both a name and a title. Using the extends keyword, we can have an Employee class inherit from the Person class, meaning every object instantiated as an Employee will also have all the methods and properties available for a Person.

class Employee extends Person {

    get title() {
        return this._title;
    }

    set title(newTitle) {
        this._title = newTitle;
    }
}

var e1 = new Employee();
e1.name = "Scott"; // inherited from Person
e1.title = "Developer";

expect(e1.name).toBe("Scott");
expect(e1.title).toBe("Developer");
expect(e1 instanceof Employee).toBe(true);
expect(e1 instanceof Person).toBe(true);

When describing the relationship between Employee and Person we often say Person is a super class of Employee, while Employee is a sub class of Person. We can also say that every employee is a person, and as you can see in the above code, the instanceof check in JavaScript confirms that an object created using the Employee class is also an instance of Person.

While every Employee object will inherit all the state and behavior of a Person, the Employee class also has the ability to override the methods and properties defined by Person. For this example, let’s add a doWork method to every Person.

class Person {

    get name() {
        return this._name;
    }

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

    doWork() {
        return this.name + " works for free";
    } 

}

var p1 = new Person();
p1.name = "Scott";
expect(p1.doWork()).toBe("Scott works for free");

By default, an Employee will behave the same as a Person.

var e1 = new Employee();
e1.name = "Scott";
e1.title = "Developer";
expect(e1.doWork()).toBe("Scott works for free");

However, in the Employee class we can override the behavior of doWork by providing a new implementation.

class Employee extends Person {

    // ...

    doWork() {
        return this.name + " works for a salary";
    }
}

var p1 = new Person();
p1.name = "Scott";
expect(p1.doWork()).toBe("Scott works for free");

var e1 = new Employee();
e1.name = "Scott";
e1.title = "Developer";
expect(e1.doWork()).toBe("Scott works for a salary");

Now, as the tests prove, objects instantiated from the Employee class will behave slightly differently in the doWork method than objects instantiated from the Person class. In object-oriented programming, we call this behavior polymorphism.

Using Super

There are times when a class will want to invoke behavior in its super class directly, which can be done with the super keyword. For example, the Employee class could implement the doWork method as follows.

doWork() {
    return super() + "!";
}

Invoking super will execute the super class method of the same name, so with the above code a passing test would now look like the following.

var e1 = new Employee();
e1.name = "Alex";
e1.title = "Developer";

expect(e1.doWork()).toBe("Alex works for free!");

A class can also refer explicitly to any method in the super class.

doWork() {
    return super.doWork() + "!";
}

Super Constructors

One common scenario for using super is when inheriting from a class that requires constructor parameters. The following Person class now accepts a name parameter during initialization.

class Person {

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

    get name() {
        return this._name;
    }

}

Now an employee will need both a title and a name during initialization.

class Employee extends Person {

    constructor(name, title) {
        super(name);
        this._title = title;
    }

    get title() {
        return this._title;
    }

}

Notice how the Employee constructor method uses super to pass along the name parameter to the Person constructor and reuse the logic inside the super class. What’s interesting about JavaScript compared to other object oriented languages, is how you can choose if and when to call the super class constructor. If I were to pick a style to remain consistent, I’d always make a call to super in a sub class before executing any other logic inside the constructor. This style would keep JavaScript classes consistent with the behavior of other object-oriented languages.

The Caveat

Now that we know what inheritance looks like in ES6, it’s time for a word of caution. Inheritance is a fragile technique to achieve re-use that only works well in a limited number of scenarios. Do a search for “composition over inheritance” to see more details.

Adventures in Angular Podcast and an AngularJS Oslo Meetup

Tuesday, November 18, 2014 by K. Scott Allen
0 comments

Last month I did an interview with the Adventures in Angular podcast crew, you can listen here.

I also did a talk at the AngularJS Meetup in Oslo. You can watch the recoding here.

Both the podcast and the Meetup talks were loosely centered around using the next version of JavaScript with the current version of Angular.

In addition to all the syntax sugar in ES6, which makes JavaScript code more expressive, the new class keyword works well for building services and controllers in Angular. As an example, imagine you are building a Pong game, and need a service to control the left paddle and a second service for the right paddle. One paddle is controlled by the keyboard, the other by AI. This is a scenario where you might, if you are brave, consider inheritance, as long as the relationship stays simple.

(function(app) {

    class Paddle {
        constructor() {
            this.x = 0;
            this.y = 0;
        }

        startMoveDown() {
            this.y += 2;
        }

        stopMoveDown() {
            this.y -= 1;
        }

        startMoveUp() {
            this.y -= 2;
        }

        stopMoveUp() {
            this.y += 1;
        }
    }

    class LeftPaddle extends Paddle {
        constructor(keyboardHandler) {
            Paddle.call(this);
            this.x = 25;
            this.y = 100;
            keyboardHandler.onArrowUp(38, () => this.startMoveUp(), this.stopMoveUp());
            keyboardHandler.onArrowDown(40, () => this.startMoveDown(), this.stopMoveDown());
        }
    }

    class RightPaddle extends Paddle {
        constructor() {
            Paddle.call(this);
            this.x = 975;
            this.y = 300;
        }
    }

    app.service("leftPaddle", LeftPaddle);
    app.service("rightPaddle", RightPaddle);

}(angular.module("pong")));

The class constructor for controllers and services will be injectable, but you’ll want to use module.service to register service classes, and not module.factory, because only .service instantiates the service using new.

Thoughts on Angular 2.0

Thursday, November 13, 2014 by K. Scott Allen
9 comments

The Great Wave off KanagawaNeil Young once sang how “every wave is new until it breaks”. The line was a poke at trendiness in the music industry, but I find the lyrical snippet is applicable to software development, too, in a number of subtle ways.

There has been a lot of turmoil surrounding the future direction of Angular, which is fair. The preview and announcements made for Angular 2.0 during ng-europe were dramatic and conveyed no empathy for the customers and development teams who have taken a dependency on the framework. Those people are left wondering when the ng-wave will break.

The Blessings and Curses of Backwards Compatibility

Web developers have always faced incompatibilities, but have also been fortunate enough to build software on top of a set of technologies and standards that have diligently preserved backward compatibility. This diligence allows the nearly 20 year old web page for the animated movie Space Jam to live on. We’ve been accustomed to building software using web standards that keep working into the future. Stability is good for business.

But backward compatibility has a price. I believe the web moves at a snails pace, which is contrary to popular opinion. However, compare the evolution of the JavaScript language to some of its peers like C# or even Java. Next year’s ECMASCript 6 release is the first big move forward for the language in nearly 20 years. Also consider the XMLHttpRequest API. The API is central to today’s applications, but it has taken the industry 15 years to standardize the API  and build the tools to make mainstream developers productive with asynchronous requests and dynamic DOM updates.

Should Angular 2.0 be backward compatible? Or should Angular 2.0 follow Py3k?

Python 3.0, also known as “Python 3000” or “Py3K”, is the first ever intentionally backwards incompatible Python release. There are more changes than in a typical release, and more that are important for all Python users. Nevertheless, after digesting the changes, you’ll find that Python really hasn’t changed all that much – by and large, we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft.

Surfing the Waves of Change

Web development feels like a fast changing environment, but a closer look will show we mostly churn in the turbulence of small, incremental improvements. It’s rare for a wave to arrive and move everyone forward.

I still believe Angular 1.x is the best wave to ride today. I already have applications in production with Angular 1.2, and at least one more on the way with 1.3.  With the core Angular code base being only 25k lines of JSDoc’ed, tested, working, healthy code, I believe the wave can keep can keep rolling for years to come.

I also believe Angular 2.0 should be a new wave that makes a break from Angular 1.x and evolves without being encumbered by backward compatibility or designs for an easy migration path. We’re still early in the history of application development on the web, and there will one day be a newer, bigger, better swell. It’s name might be Angular 2, or maybe something entirely new will come along. That’s life in the rough seas of web development, where you can either fight the waves and drown, or surf the waves and stay on top.

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…

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