#usetheplatform

As twitter, other social networks, conference submissions and drupal planet posts would suggest; I’m a bit over the moon about Polymer for Web Components. I’ve avoided front-end development workflows for years because they made no sense to me. Lots of custom bailing wire that would make a slick (but completely un-reusable) one-page-app. Nay said I! I will never do front end development!

Then Polymer happened

Michael Potter (@hey__mp) finally wore me down that we should be looking into component architecture. I saw pattern lab and went “neat, that makes sense” and then realized it was more then just a design paradygm and went “ugh, front end, this makes no sense”. He suggested we look at Polymer because “the next youtube will be done in it”. So I did. And now 4 months later, here I am writing about it non-stop. It completely changed the way I approach development with Drupal and I think is a key to sustaining and growing the Drupal community.

Drupal’s ability to be a headless, hybrid and template driven system all at the same time make it incredibly attractive for progressively decoupling and eventually moving towards entirely Web Component driven development practices. I’ve identified what I feel are five phases of web component integration:

1. Design elements in templates
2. Template-less elements
3. “Smart” / one-page apps (where we are today)
4. Headless, multi-page apps
5. Web components driving information architecture

Phase 1 as I’ve covered before is to just start making some simple design elements and wiring them into tpl / twig files. This reduces the complexity of Drupal theming in general and increases accessibility and reusability of elements, reducing the time to develop down the road. It also allows you to start “theming” across platform at a design layer since you’ve unplugged design from Drupal. This still requires all traditional roles in your web shop in order to deliver a site.

Phase 2 is to start using the webcomponents module we wrote to start replacing template files entirely through views, display modes, and display suite style theming. This reduces the need for front end developers to understand or care about Drupal, which increases our potential target audience for the platform. We can start to hire pure front-end developers and then have pure site builders integrate those design elements with little effort, leaving the big lifts for developers to integrate.

Phase 3 is disconnected, one-page app development. These apps are prototyped by themselves and then wired up to Drupal after the fact. This allows for front end developers to replace the need for site builders by envisioning their development as single “screens”. It boils Developer integrations down to a single auto-loaded file (which the 3rd video below demonstrates). This is where we are currently in the phases of progressively decoupling via Web components.

Phase 4 is effectively a routing system for stitching together the one-page apps. Beacuse one-page apps are just single element tags, it’s easy to stack those together into increasingly complex systems which click and autoload the next page without refreshing the page. This allows for smoother interactions and reduced server transactions (especially if you’ve worked in service workers which I still can’t figure out but it’s gotta be something stupid I’m missing). It also drastically improves the feel of your application / web site. This starts making site building about information architecture only as more and more of the UIs are driven by single tag / click and tweak routes methods.

Phase 5 is a bit out there (but not too far), which would have things like polymer cli’s analyze function actually write to a information-architecture.json style file which could be ingested and start building out entities and bundles to match the potential of the front end. Effectively, design drives the entire process. The one-page-app doesn’t care if a month from now you swap out Drupal for something else though Drupal’s integrations and automation will make it more attractive to use then the competition.

Showing the Web component development process via Polymer

In our own development with the platform and webcomponents module, we’ve quickly moved from Phase 1 (February) to demonstrating the capabilities of Phase 2 (March - April at DrupalCon) and now to auto-loading smart, one-page apps in Phase 3 (as of last week). Because of this, I feel that I’ve got to start unpacking some of the magic at play here and show you what our build process for new apps and elements is. I’ve put together four videos which go through some different phases of planning and creation of a new one-page app which just diplays comments from Drupal and end with a block based example for a simple drag and drop upload widget.

Video 1 starts from right after installing polymer cli (which I show you where to get). I discuss how to go about getting elements, dig into some elements to show their capabilities and start to make a very vanilla, hard coded element to display a card with buttons.

Video 2 starts to discuss properties of custom elements and how to do two-way and one-way data binding between the properties of the element and other elements, allowing you to make some slightly smarter elements. I then abstract the work of the first video and then reference it in a new element, showing the process of making stacking elements. Then I cover the (amazing) iron-ajax tag to wire an element up to a json data source and Polymer’s “template stamper” which can do conditional statements and for-each loops in your element.

Video 3 shows how we then get this disconnected app registering in Drupal and being fed data to display from drupal using the new auto-load capability of the webcomponents module. I modify the manifest.json file, place the app in the correct part of the directory structure, and then have a 1 page app that’s in the menu system, acts like the rest of drupal and securely gets data from drupal but has had almost 0 “drupal” style code written.

Video 4 quickly shows another one-page app which is using the manifest.json ‘block’ function. This allows you to make a one-page app but then present it in Drupal as a block element to place where ever you want. The block element in question is an incredibly slick vaadin-upload element which allows for drag and drop uploads to the Drupal file entity system