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.
Posts by Emil van Galen
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:
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
$.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.
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.
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.
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.
NOTE: this post updates an earlier blog post written for version 0.8 of the Karma test runner.
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.
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.
NOTE: version 7 of WebStorm already comes with built-in Karma support.
However IntelliJ IDEA 12 users will have to wait for v. 13, making this article still relevant for them.