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.


Thanks Tormi, indeed, I should have mentioned Compony, which is a relatively new (to me at least) approach to developing separate components for Drupal themes.

I really need to have a good look at Compony, especially to see how Compony components can be used beyond Drupal. It seems to be a unique, opinionated approach, in this blog post I was referring to more general common practices adopted by several projects.


Sounds like you've had a much smoother integration than I have.

Pre-made === components that were made without thinking about or made before the Drupal implementation

I've seen issues around:


The focus on prototyping in here well taken, and something I kind of glossed over in previous comments. Big believer in that, but I still struggle sometimes balancing the benefit of prototyping this way with the cost it can introduce for others who aren't involved in prototyping.

Very interesting to learn about specific problems! Having also been responsible for integrating the components and implementing the back-end has probably helped me avoid many of those problems. So it may be that this approach is best suited for very small and very large projects.


Great article @aleksip. I do agree that creating your components independently of Drupal presents all sorts of advantages. It also allows for FE Devs to work on projects even if BE work has not started or completed. This is a huge advantage compared to the traditional way of having to wait for BE work to be done before FE can start.

Drupal themes and component libraries



Reposted by Tamás Hajas