Shila theme has been developed for over a year now. I have learned many lessons from it being used on several production websites, and the theme has changed a lot. Here is a recap of the most important changes and the reasons behind them.
Background
Shila theme has always been meant to be used as a starting point for creating a new theme. It is not meant to be used as it is, although this site does use it with only minimal changes.
Pattern Lab integration has been a feature from the beginning, even before the official Pattern Lab project supported Drupal. Originally the integration started as a proof of concept, using unmodified Drupal Stable theme templates.
How to provide a StarterKit
At first Shila theme could be used to create a separate Pattern Lab StarterKit, which would then be used in Pattern Lab. All development was done in the theme project, and the theme’s Gulp script automatically copied relevant files over to the StarterKit project.
It soon became apparent that the parts that were copied over really made up the bulk of the theme, and that it would be great to be able to develop the theme using Pattern Lab alone, no Drupal required.
So the development setup was moved to the StarterKit, and the automated copying was then done the other way round. This copying was done to keep both projects independently usable ‘out of the box’, although development could now only be done in the StarterKit project. This meant that the development of the theme became dependent on the StarterKit.
It took few more months to realize the obvious: a separate StarterKit project (and copying of files) wasn’t really needed, as the theme project itself could also be used as a StarterKit. The only current requirement set by Pattern Lab is that all StarterKit files must be in a folder called dist. Thankfully this is not a problem for Drupal.
So everything was once again moved back to the theme project and the StarterKit project was abandoned. Some things just have to be learned the hard way, I guess.
Because of the way Pattern Lab currently works, the standard StarterKit installation method can’t really be used to install a development setup that would be independent of Pattern Lab itself. I’d really love to see this being possible some day, but meanwhile the approach used with Shila theme and other themes is to have Pattern Lab inside the theme project.
Hello components
By the time of DrupalCon New Orleans 2016 it seemed that practically everyone in the Drupal front end community was excited about component based theming. John Albin released the Component Libraries module, and the ‘presenter’ pattern became the de facto solution for gluing Drupal themes and stand-alone components together. Component based theming just seemed to make sense, and the time was right to try it out.
A major refactoring was done to make Shila theme component based. Basically all templates were split into two, still trying to keep very close to Drupal’s Stable/Classy theme templates. Variable manipulation was left in presenter templates picked up by Drupal, and the markup itself was moved into component templates.
Goodbye _twig-components
The component templates in Shila theme do not use any Drupal-specific Twig extensions. Drupal-specific Twig is still used in presenter templates, but these are not needed in Pattern Lab. This means that the _twig-components folder providing Drupal compatibility for Pattern Lab is no longer needed. Which is nice!
The Attribute object
One of the most useful and perhaps the most widely used of all Drupal-specific Twig features is the Attribute object. This great utility object contains no Drupal dependencies and could thus be made into a stand-alone Drupal Component.
A stand-alone Attribute component could be used by any Twig project and in stand-alone Twig component libraries. Personally I think that Attribute is so useful that it could even be made a part of Twig itself.
It would be a shame not to be able to take advantage of Attribute in stand-alone components. Fortunately Attribute variables are printed out just like strings, which provides a handy loophole: Attributes can be used as full object variables in presenter templates and as plain string variables in component templates. Admittedly this kind of use of string variables would be quite odd if not for the Attribute object connection, but it is better than nothing.
(Almost) no more PHP
I have started to subscribe to the school of thought that a themer should not have to write any PHP. Having to make significant changes to the standard Drupal templates was a good opportunity to (almost) get rid of Shila theme’s .theme file, which used to contain PHP preprocess functions that added CSS classes to different elements. Almost all of that is now done in Twig in the theme’s presenter templates. However, Twig is a templating language, not a programming language, so some things just can’t be done in Twig (at least with my Twig skills).
shila-css
With so many significant changes to Shila theme, keeping up with them in derivative themes has been quite painful, to say the least. I know, since I have been eating my own dog food!
As Shila theme is only meant to be a starting point, keeping up with changes is of course not necessary at all. But it is nice to have the option. Heavily inspired by inuitcss, the core Sass files from Shila theme were moved to a npm package unsuprisingly called shila-css. The main idea behind this is that derivative themes should not modify the core Sass files, but only configure them using Sass variables and/or extend them using new Sass partials. This should make keeping up with upstream changes much easier.
Namespaced components
The latest major change to Shila theme is the renaming of all component files and folders, adding a shila- namespace prefix to them. As theme components become more common, this allows mixing components from different projects with fewer potential naming conflicts. It also helps to avoid naming conflicts with Drupal’s own template files. A third benefit is that this should also make keeping up with upstream changes easier, as derivative themes should add their own namespace to modified or new components.
The future
There is nothing permanent except change. An exciting new development is the release of the UI Patterns module. But this blog post is already long as it is, and UI Patterns really deserves a blog post of its own.