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.
Welcome to the second installment in our series on the wunderground.com project. Click here to read part one, where we introduced the project’s use of Drupal and Angular 2, and explained some ways in which the upcoming version of Angular is a more natural fit for our progressive decoupling solution than its predecessor.
In choosing to adopt a framework without an official release, there were problems to be overcome as well. The biggest complication we encountered was that since the project is still in beta, much of the documentation is not fleshed out, and some of the specific architectural challenges we were trying to solve were not documented anywhere at all. Luckily for us, Google’s Angular team was extremely responsive to us and has worked directly with us on addressing these challenges. So before I outline our first challenge, I must give many thanks to the team, including Brad Green, Tobias Bosch, and Igor Minar for taking the time to assist us.
One of our first big concerns was how to bootstrap our components into an app. In Angular 2, the typical way components communicate with each other is by passing events out to a parent component, which then passes data back down into sibling components allowing them to respond as needed. Fair enough. Our problem was, all components are required to have templates, and since the “wrapper” or parent component would have to hold any other components on the page, its template would necessarily be the entire rendered panel page.
This is problematic because we don’t only render angular components on the page, we also allow regular Drupal-rendered panes and panes served by Edge Side Includes to coexist in the same space. Passing those out as an angular component template would defeat the purpose of rendering them server side.
The other option is to use a shared service to allow components to pass state data out for other components to read, but this is still only possible if all of those components are bootstrapped to a single app, which would still mean bootstrapping a single parent component with its own wrapper template.
The solution is simple, but as Brad Green told us at the time, “It’s never been done by anyone outside of Google.” Using what the team refers to as longform bootstrap, we are able to instantiate an app and then bootstrap each individual component inside that app. This allows components to occupy isolated regions of the DOM and still communicate with each other since they are a part of the same app. We then use a globally shared service provider injected by the root app to allow them to communicate.
Click through for a Plunker of a basic working example of this code, and keep an eye on this space for the next post, where we explain how our next big problem was solved: reusing the same component multiple times on the same page.
For more on the subject, check out my upcoming webinar Applied Progressive Decoupling: Weather.com, Angular, and Drupal on April 20th.