Decoupling from the DOM with Angular

One piece of advice you’ll run into pretty soon when working with Angular is that you should never touch the DOM outside of a directive. Especially when test-driving your components this is pretty wise. The great strength of Angular is the declarative way in which the view (HTML) works with the view model (Angular controllers). It’s almost absurd how easy it is to unit test Angular controllers. Controller functions tend to act on $scope properties, trigger or respond to events and all those things are straightforward to replicate in unit tests.

However, since Angular directives can contain controllers the temptation can be to write some pretty non-idiomatic Angular code by writing view logic that really belongs in a “pure” controller in a bloated directive that happily interacts with the DOM via the $element injected into its controller in much the way a Backbone view might.

Read More

Unit testing Angular directives that use controller and templateUrl

I spent an hour or so this morning figuring out how to unit test an Angular directive that uses a controller and a template loaded from a file (as opposed to inline). There’s a useful example in the ng-directive-testing repository but I thought a quick summary would be useful (as much to remind me the next time I have to do it as anything). Also the examples there test by interacting with DOM elements rather than directly with the directive’s scope.

Read More

GR8Conf US debrief

I just got back from my second GR8Conf US in Minneapolis. Despite the jet-lag it was well worth it.

Read More

Semantic color names in LESS and Sass stylesheets

Most people using Sass or LESS will define variables for the palette of colors in their page. Something like:

#!sass
$blackish: #231f20;
$purple: #561e31;
$pink: #da2770;
$off-white: #efefef;

.header {
    background-color: $blackish;
    color: $off-white;
}

a {
    color: $purple;
    &:hover, &:active {
        color: $pink;
    }
}

blockquote {
    background-color: $blackish;
    color: $purple;
}

This is good as far as it goes. Tweaking colors in the page is pretty easy as they only have to be changed in the variable definition.

That said, I think there are a couple of problems here.

Read More

Parameterized specs with Jasmine

Spock’s where block makes testing similar conditions for a bunch of inputs very straightforward. Recently I was working on the Groovy language definition for the Prism syntax highlighter and wanted something similar.

I used Jasmine to test-drive my code and wanted to be able to make some very similar assertions about how the highlighting operated. For example, a particular code block should contain particular characters highlighted as operator tokens. The assertions for each of Groovy’s (many) operator types would look extremely similar with the only variance being the id of the code block and the expected operator tokens. Using Spock this would be a classic case for writing a single specification method and applying a where block.

Read More

Using SASS and Compass with Gradle

I recently started helping with the Ratpack website. It is (or will be) a Ratpack app & built with Gradle. I started prototyping with a simple webapp created with Yeoman and using SASS and Compass for authoring CSS. When I migrated the work-in-progress into the ratpack-site application I initially used Ted Naleid’s method of calling Yeoman’s Grunt tasks from Gradle. Unfortunately this meant there were rather a lot of build dependencies. In order to build the app you would need Node.js, Ruby and the Compass gem installed. Peter Ledbrook pointed out this could frustrate potential contributors & Marcin Erdmann proved an example of what he meant. Clearly I needed to simplify.

Read More