Presenting component projects

Starting right from the Driesnote, it seemed like the topic of theme components was coming up everywhere at DrupalCon New Orleans 2016. Out of all the activity in this area I have been especially interested in two things: presenters and component folders. I think that they are two key pieces required for the next step, which is component projects.

Presenters

For theme components to be truly stand-alone, they should be independent of Drupal. This means that they should not use Drupal's Twig extensions. It means that the components are not restricted by Drupal's data model. The components should even be independent of the theme they are used in.

So how can components like this be used in a Drupal theme? Several people have come up with practically identical solutions. These were identified by Micah Goldbolt in his DrupalCon session as being presenters from the decades old Model-View-Presenter pattern.

In a nutshell, presenters are standard Drupal theme templates that 1) transform data received from Drupal and 2) use Twig include and embed tags to include one or more components and pass the transformed data. Presenters should be totally free of markup, and this can be achieved by using the Twig extends tag.

Component folders

When implementing theme components, placing all resources related to a particular component in the same component-specific folder seems like a natural thing to do. This is being proposed and done by several well-known members of the Drupal community.

These resources usually include at least the markup (Twig templates) and CSS, but also things like Sass files, images, JavaScript, metadata and documentation.

Getting off the island

So now we have a way to organize stand-alone components and a way for Drupal themes to use them. However, if we have stand-alone components we really should not be thinking about Drupal themes only.

Assuming that they contain Twig templates, components can be used by basically anything that supports Twig. This includes Pattern Lab, Symfony applications and client-side rendering using Twig.js, to mention only a few.

So let's get off Drupal island. From now on, I will use 'host project' instead of 'Drupal theme' whenever applicable. You can always still read 'host project' as 'Drupal theme' if you wish. But you can read it as 'Pattern Lab instance' too, for example.

Component projects

As stand-alone components can be used by different host projects, it should be possible to develop and package components as separate, fully independent projects of their own.

I think that it is a given that component projects should be standardized in such a way that they can be used 'as is' in different types of host projects.

Some other possible requirements for component projects:

  • a component project can contain any number of components

  • a host project can use several component projects

  • a host project can use component projects that are located either inside or outside of the host project

  • component projects can contain their VCS repository metadata while they are used in a host project (to allow for parallel development)

  • component projects can provide machine readable information about dependencies.

Requirements for a standard

Looking at the list above, most of the requirements are really requirements for the host projects. Only the first and last items are direct requirements for component projects.

So what would the requirements for a component project standard be? I suggest the following:

  • as simple and flexible as possible

  • as language and tool neutral as possible.

Using an existing and proven standard would of course be the best course of action. Maybe I just suck at googling, but I haven't been able to find such a standard. I will probably find one or someone will let me know about one right after this post is published...

Moving forward

We'd need to define the requirements for component projects and host projects. We'd need to agree on a suitable standard for component projects. If such a standard does not exist we'd have to define one.

I don't think it would need to be a very complicated process. We already have taken many steps in this direction.

I think that, at its core, defining component projects really should be a non-Drupal, non-PHP and non-Twig specific project. And that if one does not already exist, we should create one!

Meanwhile, active discussion related to this topic is already going on in both Drupal and Pattern Lab communities.

Comments

Submitted by Wim Leers on 17 May 2016

Permalink

Have you been working with John Albin? Your thinking regarding "presenters" and "component folders" seems completely in line with what he's been talking about.

It's interesting that we seem to be arriving at the same general conclusions, independently.

Looking forward to more of your input on the Drupal core issues to bring this to Drupal core itself :)

Thanks for your comment, Wim! Presenters and component folders are actually not something I have been working on myself until very recently. But I find them to be great ideas and since many people are working on them I feel that they could already be something to build on.

My current main interest is in trying to make stand-alone theme components as interoperable and widely usable 'as-is' as possible, with the two main use cases being Drupal themes and Pattern Lab.

Thanks, I will definitely try to be active on Drupal core issues related to these topics.

Starting right from the Driesnote, it seemed like the topic of theme components was coming up everywhere at DrupalCon New Orleans 2016. Out of all the activity in this area I have been especially interested in two things: presenters and component folders. I think that they are two key pieces required for the next step, which is component projects.