Web components, Polymer and decoupling design in Drupal

UPDATE 3: Michael Potter has posted another video walking through what we’re envisioning doing and how it works. See 3rd video!

UPDATE 2: We now have display suite and display mode integration!!! See 2nd video!

UPDATE: You should also read this great post from Mediacurrent: Benefits of decoupled architecture

Forever now I’ve heard this complaint from a friend “I can’t theme Drupal [7 & 8], it’s too hard, I just want to make HTML.” or my favorite recently, “Why can’t this be more like static site generators”. Twig in D8 at least gets us pushed in this direction and some of the work surrounding Twig + Patternlab is a step in the right direction. Showing him this, he’s been optimistic but it hasn’t been enough to get my very design / front-end-developer minded friend to bite.

How we just shattered that world view

After yet another late night discussing this at a camp (DrupalcampNJ to be exact, great even btw) we finally started sketching some ideas out. My good friend and fellow ELMSLN-er @hey__mp suggested we look into web components. He’s been on and on about them for awhile now and I typically say “no” to anything that touches front end dev; but seeing the way polymer (a system for generating, managing, sharing, and applying web components) worked completely changed my view of what design could be.

A late night conversation turned into an even later night until when I woke up in the morning I thought i had already started writing the module. Then Sunday happened, and I actually did. The entire time we talked about this workflow it seemed to make too much sense for us to accept it could be real but here goes.

In Video form

(I had to cut around 9 min so please excuse a poor transition)

In bullet form

  1. Make a polymer component (probably a front-end person / non-CMS person doing this right?)
  2. Take your existing Drupal theme (or make a new one, probably the “drupal dev” just making a baseline one)
  3. Make a directory in that theme called polymer and put the contents of the polymer components in there
  4. Enable Webcomponents and the included Webcomponents Polymer sub-module (also requires simplehtmldom for parsing)
  5. Copy and paste your polymer element into a body field, existing tpl file, anything that doesn’t filter to “only valid html”
  6. save and watch the polymer element show up in your drupal site
  7. Enable Display Suite or Display Modes submodules and wire up templates in field ui / ds ui!!!
  8. Modify the polymer template without touching Drupal; git / upload / whatever and refresh the page and see your template change reflected

This is still in Drupal 7, it’s early in development (we’ll be doing views integration, tracking usage so you can be notified when items get updated, etc) but please, tell us where we’re crazy that going this route can’t eventually turn Drupal into just being delivered by Polymer? Designers and Developers can work completely separate of each other in many workflows that this would enable and at minimum reduces your current “templates” down to single lines in files. All polymer elements are scoped at run-time too so they (reasonably) should show up the same every where they are used regardless of the context they sit with in.

Instead of accessibility testing my end site that might have the same “Card” widget reused a dozen times across a slew of TPL / twig, I can have 1 source of truth as to what a design element can look like. Polymer can be used for more then just elements (and elements can reference other elements, etc) so this is just scratching the surface. If our Mad Scientist Roadshow talk at Drupalcon gets accepted you can expect to see this workflow live.