For the recent Humangeo hackathon, team ShowMeRaces set off to create a unified road racing webapp. The project would consist of a scraping platform to pull and aggregate race data from several disparate websites, an Elasticsearch cluster for storage and quick and powerful geospatial searches, and finally an Angular/Django webapp. This being a hackathon where exploration and experimentation are put at a premium, I decided to dive head first into the new Angular Component syntax.
Angular 1.5 introduced Component syntax to the ecosystem. Components are self-contained sections of a web UI. If you are familiar with development in Angular prior to 1.5 then a Component is basically a directive and controller baked into one discrete structure that has been optimized for the best practices learned by Angular developers over its lifetime. While Angular’s standard directive and controller syntax can be very expressive, misuse can lead to an unwieldy code base. I know I’ve seen my fair share of projects with hard to debug nested controllers. Components allow for easy separation of duties on the front-end and supports one-way data flow that is easier to comprehend and allows for a consistent flow of data.
Another side benefit is that Angular 2 is based strictly on Components. While there are several differences outside the scope of this post, understanding these Component interactions in Angular 1.5 will make the jump to Angular 2 easier.
Through the experiences of developing the ShowMeRaces webapp as a guide, I hope to convey the usefulness of Angular’s new Component syntax.
The ShowMeRaces webapp is comprised of four Components and two Services. Services are used primarily as helpers that are narrowly focused, live the lifetime of the app, and are available to all Components to run view-independent business logic.
The raceService handles all HTTP API calls to our web server while the mapService handles all map specific logic such as configuration, manipulation, data addition and deletion. Having all of this functionality defined in services outside of the view/controller layer allows for easy testability as well as decoupled separation of concerns.
The 4 components developed were raceHome, raceMap, raceDetail and raceList.
raceHome is the main parent component that controls all the rest. It handles the retrieval, coordination and linking of the race data as well as reacting to events from its child components. It interacts with all of the child Components so they don’t have to interact with each other. This way the flow of data is always from the top down.
Achieving this structure is extremely easy with the new directional data binding syntax. Notice the one-way bound data objects are defined with a ‘<’ rather then the standard two way binding syntax of ‘=’.
By componentizing our Angular code we can ensure separation of duties by only providing relevant data to each component. For example the selectedRace object (the currently highlighted race) is needed by all three Components while the raceListBounded list (the list of races currently visible on the map) is only needed by the raceList component.
Component Lifecycle Hooks
Component lifecycle hooks give developers a set of specific methods that will be invoked by the framework during the lifetime of the component. For example $onInit sets up the controller, and $onChanges allows the controller to execute code when one of the bound objects changes. For the raceDetail component it’s important to know when the selectedRace changes in order to update the detail map by adding a new “selected race route”.
Function Call Backs
Since we are dealing with one-way data bindings, the child components need a way of telling the parent raceHome component that the user has selected a race. Component syntax allows you to define callback functions in the bindings to accomplish this by using an ‘&’ in the binding configuration.
With that setup, we have created a good symbiotic relationship between Components, with data flowing down and actions propagating up.
Leaflet Angular Integration
During development, the UI-Leaflet directive allowed me bite off small chunks of map functionality at a time. I first added the default map with markers for race start locations, and later on in the development cycle, I added race routes and map layers with little additional work. The directive also behaves as expected for an Angular library in that data changes are immediately propagated to the screen.
Lets look at how we can incorporate all of these pieces of Component syntax into the raceMap Component, which will be our own data and interaction wrapper around the Leaflet map directive.
The basic structure of the raceMap Component definition.
- Bindings and template URL
- Object declarations
- Lifecycle hooks
- Action function declarations
The view template for the raceMap component is used to wire up the UI-Leaflet directive to the objects being manipulated by the controller:
The $onInit function is used to configure the base map objects, as well as define any event hooks necessary for communicating map changes or interactions to the raceHome Component.
The $onChanges method is heavily used in the raceMap Component. Most of the time in Angular with one way binding, simple values like strings or dates can just directly link the data to the DOM and as new data is received the DOM is updated. However, with the raceMap Component, when we receive new data (i.e. a list of geolocated races), the data needs to be formatted and passed to the Leaflet Directive to update the map. This is also a perfect opportunity to utilize a decoupled mapService for this “formatting” logic.
And we’ve come full circle. Angular has been a useful tool in Humangeo’s ever expanding toolbox. As a webapp framework we’ve used it to create beautiful and functional websites with large teams quickly. I hope that my experiences using the new Angular Component syntax and UI-Leaflet library have been helpful to those of you choosing to live on the forefront of technology. Thats what we do and if that excites you, we’re hiring!