The Grails side of this is pretty standard. I've used the handy resources plugin to manage my client side static resources like images, js, and css files. It allows you to define dependencies between these resources and then bring the required ones into a page just by specifying the top level of the hierarchy. There is a Grails Controller (shown below) with two kinds of actions. There are pass through actions (list and show) that defer to AngularJS, and end points for restful calls (query). PhoneService is a Grails service that handles the actual data. In a real application it would be backed by a proper data store, but here I hardcoded the actual JSON from the AngularJS tutorial.
Though there is an AngularJS plugin for Grails, I didn't see any reason to use it. The Grails resources plugin makes using AngularJS so simple, and I like having direct control over which version of AngularJS I use and where the files are put.
Much like Grails, AngularJS has its own set of controllers (for page manipulation), services (for general purpose tasks), and dependency injection to tie everything together. The DI feels a lot like Groovy with the way that injection takes place by name automatically. If you look deeper it starts to look a lot like Guice. Below are the Angular controllers used in this application to get JSON data and binding it to the page via $scope.
Grails and AngularJS Together
There are limitless ways that you could combine Grails and AngularJS. By posting this I hope to gain some new insights. I favor Grails quite a bit here just because I am more comfortable with Groovy. Think of this example as a Grails app which delegates to an AngularJS sidecar specializing in putting the final touches on the view layer.
Grails vs AngularJS responsibilities
|URL mapping for full page transitions||client side data binding and dom manipulation (single page changes)|
|provides RESTful services||makes the AJAX calls|
|server side DI with Spring||client side AngularJS DI|
Rather than use AngularJS routing, I let Grails handle it (mostly because I am more familiar with Grails). You can see in PhoneController above that the pass through actions act very much like AngularJS routes. They map a url to a template (by Grails convention) and an AngularJS controller (by passing an explicit value to the template). In this case the template is a Grails .gsp.
Grails and AngularJS share the templates which in this case are .gsp files. There are two passes to transform these files now. First Grails compiles the .gsp on the server and applies tag libraries, then AngularJS applies it's bindings and directives on the client. This is where AngularJS shines and I let it do most of the work. One thing to remember is that since Grails encodes the output of tag libraries, you can't use the AngularJS binding inside them. For example...
Getting Grails and AngularJS to communicate effectively is simple once you realize that Grails params and AngularJS $scope are both the state that the respective controllers care about. So I found a way to stamp the Grails controller's params onto the AngularJS controller's $scope using ng-init. The main.gsp is a layout that I apply to all my Grails .gsp files. It is basically a place to put common elements that will appear on every page. You can see how I am taking this opportunity to always set the ng-controller (which was specified by name in the Grails controller) and pass the Grails params into it with ng-init.
AngularJS provides resources for making rest calls. This is a great way to communicate with the Grails backend. To remove a lot of boilerplate code I created a service that constructs resources based on Grails URL conventions. You can see in the AngularJS controllers above where I make use of the service named 'Grails' to get phone data. The code for this service is below. It simply substitutes Grails controller, action and id values for their placeholder in the url. It will default to values found in $scope (which were copied from the Grails params if you remember).Unit Tests
Grails itself offers great support for writing tests, especially with the 2.0+ enhancements that allow better Spock integration. I must say that testing my code with Spock is bliss with its concise syntax, built in mocking, and intuitive assertions.
Functional tests run against your app externally, usually through some type of browser automation. AngularJS provides end-to-end testing to accomplish this. These tests are described with Jasmine just like AngularJS unit tests. They are executed in the browser and are blazingly fast. AngularJS e2e tests are awesome, but I used a Grails based solution instead.
Geb is a Groovy way to automate a browser and it works well with Spock to write Grails functional tests. It's basically a Groovy DSL on top of Selenium/WebDriver. Even though it is not as fast as AngularJS e2e tests, I am more familiar with these tools and I like the page object pattern that Geb uses to separate browser automation in the test from the specific markup of the page.
Above you can see the definition of a page. Most of the CSS selectors that address page elements can go here. Aside from avoiding repetition of these selectors, it makes the tests less brittle. When there are changes to the markup you just make a corresponding change to your page definition and all your tests still pass. There's no need to change the test itself unless the behavior of your test conceptually changes.
Below you can see the related test. The setup method navigates to the specific page and the tests use the page object definitions to manipulate and make assertions about the page. Note how I am able to pass 'phoneThumb' an index so that I can click arbitrary thumbnail images. I think this makes for very readable and robust tests. Converting the AngularJS e2e tests from the tutorial to Geb was very intuitive.
Running the Geb tests was not so straight forward. There is a Geb plugin for Grails that does some basic setup of Geb inside of Grails, and there is tighter integration to be had by following this tip from the Geb author. The plugin allows you to run the tests from the Grails command line, but I had to resort to a bit of a hack to run the tests from my IDE. Basically I needed a way to configure Geb outside of the Grails app.
Speaking of Geb configuration, I have a few observations about my choice of driver. I tried HtmlUnitDriver, FirefoxDriver and ChromeDriver. HtmlUnitDriver just didn't work for my tests. FirefoxDriver worked out of the box, but was slow. ChromeDriver was fast (much closer to AngularJS e2e speeds) but there is a minimal amount of setup to be done on your machine first.
AngularJS brings a lot of the same good things to my client code that Grails brings to my server side code (structure, DI, tests). CoffeeScript makes my client code look and feel more like Groovy (less boilerplate, many common idioms). Overall my client side scripting is now a first class citizen and sits right beside the rest of my code (literally and figuratively).
All the code is on Gtihub. Feel free to use this as a starting point and send pull requests when you figure out improvements.
- Run in jenkins build on headless server and capture test failures (bonus points for code coverage)
- Use Testacular rather than js-test-driver to run unit tests.
- Replace CSS and HTML with Less and Jade respectively.
- Full CRUD with RESTful Grails endpoints.