In an ongoing web project with Weather Underground, the Mediacurrent development team is breaking new ground with decoupled Drupal and Angular 2. The endeavor has required refactoring the Presentation Framework originally built for Weather.com from dependent on Angular 1 to being javascript framework agnostic. This blog series explores how Mediacurrent, in collaboration with the Angular team at Google, has solved for several architectural challenges.
For the wunderground.com project, our mandate was to use the same Drupal 7 platform originally built for weather.com. The Presentation Framework, as has been written and spoken about extensively elsewhere, is a progressive decoupling tool allowing front-end developers to write pieces of Angular 1 functionality without knowing any Drupal API’s. These components are then ingested by Drupal and turned into CTools content types, aka Panels panes. This allows editorial teams to place these client-side rendered widgets on pages and create new pages and layouts by themselves.
One of the requests of the Wunderground team in beginning this effort, though, was that instead of starting a new project using Angular 1, they wanted to push into new territory and use the not-yet-released Angular 2. In refactoring the Presentation Framework built for weather.com to work with a new javascript framework, however, we encountered some interesting architectural challenges. Angular 2 is a ground-up rewrite of the original framework, and the Presentation Framework as it existed was tightly coupled to Angular 1. Since wunderground.com is being built on the exact same codebase as weather.com, our job was to rebuild the foundation underneath the forty story building.
In some ways, Angular 2 is a more natural fit with the framework. For one, we had imposed an independent(-ish) structure on our angular widgets, placing each distinct piece of functionality in a separate directory to be ingested by Drupal as a separate CTools content type. This compartmentalization of logic is not inherent to Angular 1. However, Angular 2 is component based, and components operate under very similar suppositions of compartmentalized logic to that we’d originally imposed.
Another way Angular 2 fits better with the existing build has to do with our lazy loading model, which attempts to defer the loading and rendering of components until they are scrolled into the viewport. In Angular 1, given the way our dependency trees were handled by Drupal, this was an extremely complex problem to solve and ultimately involved making tough sacrifices of front-loading more javascript and css assets than was ideal (this system is much better now and continues to be improved upon). The Angular 2 build, however, gives us this piece of the puzzle for free, giving us the ability to dynamically load components, including all assets associated with them, saving us valuable time in our initial page render.
In our next installment, we will examine the first major architectural challenge our team encountered in the project, exactly how to bootstrap our components on the page.
Additional Resources
Migrating Weather.com to Drupal: The Presentation Framework | Blog Post
Supplying Thumbnails to Your Headless Drupal Front End | Blog Post
Decoupled Drupal 8 | Presentation