About Emil van Galen

My name is Emil van Galen, I work for JDriven. I'm passionate about software development and continuously seeking for ways to improve code, learn new technologies, improving software design and keeping things fresh.

AngularConnect 2016 conference report episode 1

AngularConnect 2016, held on the September 27th and 28th, was the first Angular conference since the final release of Angular 2.0.
From our company (JDriven) we, 3 front-end loving colleagues, attended this conference and would like to share some of the noteworthy things we’ve learned during the conference.

To allow us some time to write things down as well digest what we have learned, we intend to publish this conference report as a series of 2 or 3 episodes.
In the (first) episode we will go into the topics of performance, support (also for Angular 1.x) , tooling and security.
Future episodes will most likely go into the topics architecture, mobile, data, seo and / or testing.

Performance

One of the hottest topics during the AngularConnect 2016 was performance.

ac16-1-image05

Angular 2 is without any optimizations already multiple times faster than Angular 1.x

But you can make Angular 2 even faster by:

  • Choosing a more optimized change detection implementation (i.e. OnPush with immutable data model)
  • Pre-compiling your templates to executable JavaScript during your build.
    This process is called Ahead-of-Time (AoT) compilation and is done by a new tool called the Angular Compiler.
    The Angular Compiler (also available as a webpack plugin) will generate all necessary DOM manipulation of your templates (i.e. create DOM nodes, interpolate values) as executable JavaScript code (i.e. document.createElement and innerText = ...). Big advantage of using the AoT compilation is that the framework no longer needs to compile templates at runtime (saving a lot of startup time). Additionally you no longer need to ship the template Just-in-Time compiler with your web app, saving some precious kilobytes.
  • Loading only the main part of your web app during bootstrap and lazy load additional bundles. The proper way for lazy loading is to use the Angular 2 Router, which also supports pre-loading additional bundles in the background after initial bootstrap of the application.
  • Using Angular Universal to pre-render a page on the server-side.
    This way the user no longer has to wait for Angular 2 to bootstrap before the actual content can be seen.

The talk “How fast can web-apps be?” provided some great insights on how to significantly improve load-times for any mobile web app, especially on slower 3G mobile connections.

Additionally, you could also optimize data traffic between the browser and back-end by using GraphQL instead of REST.
Using GraphQL, the client (browser) can query (and receive) only the data that it wants. The third-party Apollo GraphQL client also supports GraphQL batching, which saves up queries and executes them in a single request (this was only indirectly mentioned during the talk).

References:

Support

In the opening keynote, Jules Kremer gave us a lot of useful information about the support of both Angular 1 and 2.

Angular 1 support and upcoming features

The Angular team traditionally uses the statistic “30-day active visitors” of the Angular documentation site, to get an idea of how many developers are using Angular.

ac16-1-image02

Based on these statistics presented during the talk, Angular 2 is already used quite a lot.
As for of how long Angular 1 will be supported Jules Kremer said during the talk:
“We will continue to support Angular 1 until this chart flip-flops, and the majority of the developers are using Angular 2”

Personally I think this is not very concrete, and it also contradicts an earlier, more concrete, answer from Brad Green during the ngEurope 2014 conference, where he said that Angular 1 will be supported for at least 2 years (if I’m not mistaken).

Although Angular 2 is released, version 1.x appears to be quite actively used:
“Component architecture that was landed in Angular 1.5 has proven to be very popular.
So the team is focussed on improving that, as well as aligning to jQuery 3, improving performance and reducing code size”

Angular 2 semantic versioning, future major releases and deprecation policy

Starting from the final release of Angular 2 (version 2.0.0), all future releases will follow the rules of semantic versioning.

ac16-1-image06

Basically this means that until the major version of Angular is bumped to 3.0.0, there will be no breaking changes whatsoever in the API.
Any versions prior to 3.0.0 should therefore only contain bugfixes and backwards compatible changes.

Besides semantic versioning, the Angular team aims to follow a release cadence of 6 month between major releases as of now.

ac16-1-image04

Furthermore the API documention on angular.io now indicates if an API is either
“stable” or “experimental”

Starting with Angular 2.0.0, a deprecation policy is introduced for its “stable” API’s.
Due to this policy a “stable” API cannot simply be deleted (or altered in a breaking way) in the next major version. Instead it will be marked as deprecated and will be removed 2 major versions later.

The deprecation policy doesn’t exist for “experimental” API’s, but the Angular Team will still follow the semantic versioning rules, meaning that an “experimental” API cannot be removed (or altered in a breaking way) prior to major release.

References:

Tooling

Angular Compiler

The inner workings of the Ahead-of-Time (AoT) Angular Compiler where explained in detail during the talk “The Angular 2 Compiler”.

It was fascinating to see how Tobias Bosch has managed to achieve so many performance wins. And he claims to have some more tricks up his sleeve to make template rendering even faster and also make even smaller web apps.

Besides the huge performance wins of the Angular Compiler, I really like the fact that it can also output TypeScript code with type information (besides ES5 and in the future ES2015), which allows you to type check your templates.

Angular CLI

ac16-1-image01

Traditionally while developing in Angular 1.x you had a huge number of choices in third-party tooling, especially build tooling.

As part of Angular 2, the Angular CLI (Command Line Interface) was created in order to make tooling more uniform. Originally, Angular CLI used SystemJS but they decided to switch to Webpack because of feedback from the community.

With the new Angular CLI, you can quickly scaffold a new application and then add new parts (e.g. components) to it.
Besides uniformity in tooling and productivity, Angular CLI applies the Angular 2 Style Guide code conventions (e.g. for directive and file naming conventions).
Additionally, the CLI also brings a TSLint configuration with rules of Codelyzer to lint your code against the Angular 2 style guide.

Another reason for using the Angular CLI is that in the future it will help with the migration to future Angular releases.

While creating the Angular CLI, the Angular team created a suite of Webpack plugins that can also be used stand-alone. For example they have created a Webpack plugin for the (AoT) Angular Compiler which can also be used without the Angular CLI.

Angular Universal

Angular Universal allows you to do server-side pre-rendering of your Angular 2 application.
The only talk about Angular Universal was called “Universal Tooling” which was primarily about the upcoming Universal support in Angular CLI.

Angular CLI will allow you to easily scaffold an Angular 2 application that uses server-side pre-rendering.
Additionally they aim to add additional Codelyzer linting rules, to prevent developers from accidentally referencing the DOM (i.e. using window. and document) which is not possible when using server-side rendering.

Angular Universal apparently has a pre-rendering and re-rendering mode which you will be able to specify to Angular CLI. For what I understand the re-rendering mode will be the default mode which uses a server component to generate pre-rendered HTML, whereas the pre-rendering mode will generate your whole site as static HTML during your build.

Since Angular Universal doesn’t actually need Karma or Protractor for testing, they also intent to support direct testing which will save unnecessary resources and additionally improve performance.

Augury

ac16-1-image00

Augury is a development visualisation tool for Angular 2 that is built as a Chrome browser plugin. It’s what Batarang used to be for Angular 1, only much nicer, visual appealing and feature rich (IMO).

One of the nice features of Augury is that it shows you the hierarchy of your components and also flashes components that changed while you use your web app.
Additionally, it also allows you to see the state (its properties) of your component, and also allows you to change it and emit the events of your output properties.

Furthermore, it also comes with an dependency injection graph that also clearly shows from where in the injector hierarchy a component / pipe / service is coming from. A similar feature also existings for the router tree.

Augury also comes with search support (e.g. inside an injection graph).

And last but not least… if you select a component in Augury, this change with also be reflected in the $a (similar to $0 that contains the last inspected element in Chrome) making it possible to use it the console of the Chrome Developer Tools.

References:

  • “Angular CLI”: Video, Slides
  • “Look Deeply Into Your App with Augury”: Video, Slides
  • “Universal Tooling”: Video, Sides

Security

During the conference there were 2 talks about security.

The talk “Cross Site Request Funkery: Securing Your Angular Apps From Evil Doers” was about Cross-Site Request Forgery (CSRF) and very nicely explained how CSRF works.
Additionally it debunks all the common myths about why you might not need to protect yourself against CSRF. And finally it explained how you can easily protect yourself from the ‘baddies’ by configuring Angular 1 & 2 to add the “X-XSRF-TOKEN” request header in combination of generating a “XSRF-TOKEN” cookie on the back-end.

The other talk “Secure your Angular applications” primarily went into Cross-Site Scripting (XSS) and how to protect yourself against it. Also it explained why it’s never possible to be really secure using blacklisting, and that instead whitelisting is the only really safe approach.

Angular 1.0 up until 1.5 contained an expression sandbox (using for expression inside your templates) intended for protection against XSS attacks.
As it turned out the blacklisted approach of the expression sandbox is unable to offer watertight protection, even though it was improved in each Angular version up until 1.5.

In the upcoming Angular 1.6 release the expression sandbox will be removed, and Angular 1.6 will have no sandbox, just like Angular 2.

security-angular-1_6

Instead of relying on imperfect blacklisting, one should use the Content Security Policy (CSP) whitelisting approach. To be really safe you should configure CSP to disable all inline javascript (all <script> tags should have an src attribute). This however requires us to enable CSP mode in Angular 1 causing it to no longer use eval and making it 30% slower.

References:

  • “Cross Site Request Funkery: Securing Your Angular Apps From Evil Doers”: Video, Slides
  • “Secure your Angular Applications”: Video, Slides

Grasping AngularJS 1.5 directive bindings by learning from Angular 2

In AngularJS 1.5 we can use attribute binding to allow easy use of input-only, output-only and two-way attributes for a directive or component.

Instead of manually parsing, watching and modifying attribute values through code, we can simply specify an attribute binding by adding a property to the object hash of:

In this blog post we will learn how attribute bindings differ between AngularJS 1.5 and Angular 2 and what we can learn from Angular 2 to make your HTML and JavaScript in Angular 1.5 more descriptive.
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

ngEurope: about AngularJS 1.3, new router and the future 2.0

Being passionate about AngularJS, me and two fellow JDriven colleagues visited the ngEurope conference.
The amount of presentations during ngEurope was somewhat overwhelming, especially during the mornings without any scheduled break.

Good thing I made some notes, that the slides are already available on-line and that someone published quite detailed notes for all sessions.
Without all this I might simply have forgotten about some very interesting and relevant details.

During ngEurope there was a all lot of attention for the just released 1.3 version of AngularJS and the coming 2.0 release.
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

Joy of Coding… and mutation testing in Java

For many years now it has been good practice to write unit tests for your source-code.
And also to use test coverage reporting to see how much of your code is covered by tests.
Although line + branch coverage reporting is quite useful, it doesn’t tell you how good your unit tests actually are. Hence it’s even possibly to achieve 100% coverage without even a single assert in your tests.

Being interested in better ways of testing I attended the “Mutation testing” workshop during this years Joy of Coding conference.
Mutation testing is a radical different approach of executing and analyzing the result and coverage of your unit tests. Instead of measuring how much of your code is “accessed from” your unit tests it determines how much of your code is actually “tested by” your unit tests.

Continue reading

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

NOTE: this post updates an earlier blog post written for version 0.8 of the Karma test runner.

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 version 0.10 of the the Karma test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.
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