Drupal themes and component libraries

In the past four years that I have been building component-based themes for Drupal projects I have never created a separate component library. And I have never used the same component templates anywhere else than in the Drupal theme that they were originally developed for.

The projects I have worked on have been small, at least in the sense that in most them I have been the only developer. My clients have never required building a design system, style guide, pattern library or a component-based theme.

So, despite all this, why have I wanted to use a component-based approach?

Prototyping and developing a Drupal theme without Drupal

The single most compelling reason for me to develop component-based themes has been the ability to prototype and develop most of the theme independently of Drupal, right from the beginning of a project.

Clients often do not have a clear idea of what they actually want, and static wireframes or Photoshop comps, even with variations for mobile and desktop, leave too much to the imagination. Prototyping and presenting designs in real browsers, in different viewport sizes, can be really helpful in understanding possibilities, limitations and requirements.

Using actual theme templates for prototyping means that a lot, if not most, of the work from this stage is usable for the final implementation.

I have also found that client requirements can change a lot at this stage, and that these changes can affect the back-end implementation. The ability to discuss and quickly modify a real web page prototype even before installing Drupal can save a lot of work on the back-end as well.

A shared way of thinking

Building something from components is essentially a very simple idea. Practically everyone knows Lego bricks and how you can build larger structures from different kinds of smaller bricks. Using Pattern Lab or similar tools it is possible to show theme component templates in isolation, something that is not trivial to do in Drupal itself. When components are identified, named and discussed together with the client, designing and building layouts for pages can become much easier.

Also, while it is not something that can be easily measured and compared, I do believe that starting from a more generic, component-based mindset instead of a Drupal-specific one can bring better results.

So what about all the extra work?

When the initial work has already been done in a component-based starter theme, there is very little work required to start prototyping component templates and full web pages in a tool like Pattern Lab.

Component-based Drupal themes are not so different from vanilla Drupal themes. The main difference is that currently in most, if not all, component-based themes regular Drupal templates contain a Twig include statement to include a namespaced component template, which is organized in a separate folder structure. I would say that this is more of an organizational difference, both mentally and in the file system, than anything else.

I have found that most of the extra effort in component-based theming comes from creating demo data for an external tool like Pattern Lab. However, compared with the effort required to arrive at a shared vision based on iterations of static files, or prototyping with something else than the theme templates, creating demo data could actually take a lot less work.

A thing worth noting is that component-based theming and the use of external tools and demo data are not an all-or-nothing approach. It is possible to use both vanilla Drupal templates and component templates in the same theme, and create as much or little demo data as required.

Separate components and component libraries

Theme components can also be developed, packaged, distributed and installed separately from a Drupal theme, either individually or as a component library. Doing so opens up a lot of possibilities that might be especially interesting to large organizations and projects, and even more so if the components use only vanilla Twig.

Unfortunately common best practices for such technical implementations and related workflows do not yet exist. If you only need to build one specific component-based Drupal theme, separate components and component libraries are unlikely to be worth the extra effort.