Experiences at Google IO 2016

From May 18-20 myself and Richard attended the Google IO 2016 conference. We both visited different tracks and have some different experiences we’d like to share. Here are mine. Read on about topics in the likes of VR, Progressive Web Apps, and Artificial Intelligence. For a quick impression have a look at the photo album.

Google CEO Pichai during Google IO keynote at the Amfitheater
Continue reading

Using `$q.defer()` in AngularJS? Try the $q ‘constructor’ instead.

Although I’m a great fan of using the ($q) Promise API in AngularJS, I never really liked using $q.defer() and its Deferred API. I always found using var deferred = $q.defer() together with $.resolve(..) and $.reject(..) to be too verbose.

After recently checking the $q service documentation I stumbled upon the $q constructor that results in way less verbose code.

To illustrate the usage of the $q constructor I will create a function that wraps the result of a Geolocation#getCurrentPosition invocation as an AngularJS $q promise.

Using the traditional $q.defer() approach the function wrapper will look like this.

When using the $q constructor, I could rewrite the code as follows, resulting in less verbose code:

And since in this case we are merely passing through the arguments of the success and error callbacks, I could rewrite the code to be even smaller:

As you can see, using the $q constructor produces code with less boilerplate, making it more readable in the process.

Notice that although it’s being called the “$q constructor” we are not actually doing a new on $q.
Possibly, the AngularJS team calls it this way because it mimics the ECMAScript 2015 Promise constructor API.

Next to the $q constructor there are some other alternatives to using the verbose $q.defer().
In most cases you can probably use a less verbose alternative as is nicely described in this blog post that I stumbled upon while doing some additional research for my own blog post.

ngImprovedTesting 0.3: improved ModuleBuilder with lots of bug fixes

NOTE: ngImprovedTesting is AngularJS library to make mock testing AngularJS code more easy.
For more information about ngImprovedTesting be sure to read its (updated) introductory blog post.

Just released version 0.3 ngImprovedTesting with a much improved ModuleBuilder.

Prior to 0.3 usage of ngImprovedTesting might be troublesome due to fact that the ModuleBuilder:
Continue reading

ngImprovedTesting 0.2: adding $q.tick() to improve testing promises

NOTE: Just released version 0.2.2 of ngImprovedTesting to fix issue #6 causing chained promises (i.e. .then(...).then(...)) not to executed by a $q.tick(); also see README of the GitHub repo.

After quite a while I finally got round to creating version 0.2 of ngImprovedTesting.
The ModuleBuilder API is unchanged and still makes mock testing AngularJS code much easier (be sure to read this blog post if you are unfamiliar with ngImprovedTesting).

Version 0.2 of ngImprovedTesting brings you the following interesting improvements:

  • ngModuleIntrospector no longer uses internal AngularJS API.
  • mocks can now also be created manually using the (global) “mockInstance” function.
  • features a more descriptive way of testing promises by adding the tick() method to $q.
  • offers an module called “ngImprovedTesting” to be able to use $q.tick() in your tests without having to use the ModuleBuilder API (which automatically includes the module).

Continue reading

Web-components like AngularJS directives

As you may already know web components consist out of a set of technologies which are combined to create a custom element for use in your HTML markup. The main additions, as described in several blogposts, are HTML imports, Shadow Dom and Templates combined with isolated scripts and styling. (If these concepts are new to you i suggest you read up on web components at WebComponents.org).

This blog post has a living example on plnkr.co.

Continue reading

ngImprovedTesting: mock testing for AngularJS made easy

NOTE: Just released version 0.3 of ngImprovedTesting with lots of bug fixes.
Check out this blog post or the README of the GitHub repo for more info.

Being able to easily test your application is one of the most powerful features that AngularJS offers. All the services, controllers, filters even directives you develop can be fully (unit) tested.

However the learning curve for writing (proper) unit tests tends to be quite steep.
This is mainly because AngularJS doesn’t really offer any high level API’s to ease the unit testing. Instead you are forced to use the same (low level) services that AngularJS uses internally. That means you have to gain in dept knowledge about the internals of $controller, when to $digest and how to use $provide in order to mock these services. Especially mocking out a dependency of controller, filter or another service is too cumbersome.

This blog will show how you would normally create mocks in AngularJS, why its troublesome and finally introduces the new ngImprovedTesting library that makes mock testing much easier. Continue reading

Understanding and fixing AngularJS directive rendering and parsing

NOTE: This blog post is originally written for AngularJS 1.2.x; in 1.3.x the “input not showing invalid model values” has been fixed.
Although 1.3.x still has the “inconsistencies in how AngularJS parses data entry” the solution from this blog post isn’t working for 1.3.x but I will try to find a fix for this within the next few weeks.

A while ago I noticed that AngularJS doesn’t show invalid model values bound to an <input/>
There is also an open bug report about this: issue #1412 – input not showing invalid model values

The bug can be easily illustrated through the following example:

While running the example displays letters = 1 but the <input/> element remains empty.
Additionally notice that the <input/> element (due some custom CSS styling) has a “red” background to indicate that its value is invalid (since it doesn’t match the regex of ng-pattern).

In this blog post I will dig into how AngularJS handles rendering, parsing and validation and will finally provide a workaround / solution for this AngularJS bug as well as some other improvements.

Continue reading

Integrating Karma 0.8 tests in Maven with Sonar(Cube) test coverage

NOTE: this blog post was written for version 0.8 of the Karma test runner.
An updated blog post for the new Karma 0.10 can be found here.

For my current project we are using Maven to build our AngularJS application.
Furthermore we use Sonar (recently renamed to SonarCube) to monitor our code standards / best practices and unit test coverage.

In this blog post we describe how to integrate the Karma (Testacular) test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.
Continue reading

Quickly experiment with AngularJS (and Jasmine) using these Plunks

When experimenting with AngularJS features I often create a so-called Plunk on http://plnkr.co/. Although this site provides built-in templates for AngularJS, I found it useful to create my own since:

  • The “1.0.x (stable)” / “1.0.2 + Jasmine” templates use old versions of AngularJS;
  • “1.0.2 + Jasmine” template solely outputs Jasmine results but no AngularJS content.

These are my Plunks (based on the original Plunker templates):

Safe-guarding AngularJS scopes with ECMAScript 5 “Strict Mode”

Having a history as a Java developer I prefer declaring the complete JavaScript object at once through an object literal; in a similar fashion as your would declare a class in Java.
In my opinion adding new properties “on the fly” to a JavaScript object is a very bad practice:

For the same reasons I dislike how properties are declared in an AngularJS application: