The Benefits of Component-Driven Development

The biggest change that Drupal 8 brought to the front-end development process was the introduction of the Twig templating engine. Twig templates in Drupal 8 replace the PHP Template files used in Drupal 7 (recognized by their extension, ".tpl.php"), and they come with many benefits.

Most importantly, embracing Twig means that Drupal's front end is no longer powered by a custom templating engine that is unique to Drupal, but instead is powered by an engine that is used by many different kinds of applications. There's a good chance that a developer working with Drupal for the first time may already have experience using Twig templates on a different application. This reduces the learning curve for front end developers, and helps to get Drupal "off the island."

Besides being a more widely-used tool, Twig also brings more flexibility to the front-end by making templates extensible, which just means that we can define a template in one place and reuse it in many places. This reusability sets us up for being able to take a more component-driven approach to development.

A component is simply a discrete element that may appear in multiple places. To understand what a component looks like on a website, imagine that a site has a content hub, and that hub shows teasers of the latest events, blog articles, and resources. We can build a generic component that defines the appearance for each item in the hub. Maybe it looks something like this:


We can extend that component so that it applies to events, blog articles and resources. For each type of content, all we need to do is define what pieces of data will be used in the template. Here's what that component looks like for each of the content types:

three components

Now we have a component, defined once, that is used by three types of content. Going forward, any updates to the component template or styles will be reflected in all three types of content.

The Drupal community has been quick to embrace this approach to development. Using some of the tools developed within both the Drupal community and the greater front-end community, we are able to build themes that are more efficient and more modular. One of these tools is the Component Libraries module. This module simply gives us the ability to create template files (with their associated CSS and JavaScript) that can live anywhere within our Drupal filespace, and allows us to give our templates their own namespace. So now we can have all kinds of templates everywhere, instead of just in the "templates" directory of our theme.

With the Component Libraries module in place, and our templates discretely defined, we're now in a better position to document our work. This is where a style guide comes in. By now, the benefits of using a style guide are widely known, and many also understand that the only way a style guide is beneficial is if it is current. By using the KSS Node library, we can create a living style guide that is powered directly by our component templates. Here's what our hub component might look like in the style guide:

style guide

Here at Duo, we are now putting all these tools together so that new themes we develop for Drupal 8 are already configured to support component-driven development. Our current starter theme is built with the following tools:

Are you interested in learning more about how component-driven development can help you?

Ready to start a conversation?