All the great work already done and to be released by the Layout Initiative has inspired me to think about how core’s definition files can be used in component-based theme development. As a result I am now happy to announce two Drupal modules and a Pattern Lab plugin which enable new ways of using core’s definition files.
Layout definitions have superpowers
Layout definition regions can be used for both blocks and fields, to create both page-level layouts and more intricate layouts for smaller pieces of content and components.
Data mapped to layout regions can also be used in component template files to configure the component in some way, instead of just displaying the data as it is.
The terms ‘layout’ and ‘region’ can be a bit misleading in that last use case. However, I am not aware of any reason why layouts should not be used in this way. Layout definitions have been successfully used as de facto component definitions in component-based theming for quite a while now. There are no ugly hacks involved, and soon Drupal core will even have UI support for it.
Layout definitions can also reference an asset library, which can be used to define all the assets of a component.
Introducing the Multiple Definition Files module
So, what could be done to improve component-based theming with these superpowers we already have in core?
One of the general principles of component-based theming is that all files related to a particular component should be located in a component-specific folder. However, Drupal core currently only supports extension (theme) specific definition files for asset libraries and layouts. Wouldn’t it be nice to have component-specific definition files?
I decided to try an approach that uses existing definition file types, with no specific requirements as to where they should be located. The Multiple Definition Files module recursively scans the default theme’s directories for .libraries.yml and .layouts.yml files and then merges all found definitions to the theme’s main definition files. I haven’t found any problems with this approach so far, and I think it would be great to have this type of functionality in core some day.
Introducing the UI Patterns From Layouts module
What about the great features provided by UI Patterns? To use UI Patterns we still need to create .ui_patterns.yml definitions, or Pattern Lab and Fractal users can install an additional module that exposes their respective component definition files as patterns.
UI Patterns includes the UI Patterns Layouts module that exposes patterns as layouts. But what if it was done the other way round? Could layouts be exposed as patterns?
Thanks to another core layout definition superpower, support for arbitrary properties, we can add the preview values expected by UI Patterns to the layout definition file. And thus was born the UI Patterns From Layouts module!
Introducing the Drupal Definition Files plugin for Pattern Lab
Being a Pattern Lab user and contributor, I naturally turned my attention to Pattern Lab next. If Drupal core definition files could already be used for everything in Drupal, why not add support for them in Pattern Lab, removing the need to create Pattern Lab specific files?
So, I wrote a Pattern Lab plugin that adds support for .layouts.yml files and the arbitrary preview data section. The Drupal Definition Files plugin also supports defining the data for the base pattern and all of its pseudo-patterns in just one file. This is a nice feature for projects that have many pseudo-patterns.
Data Transform Plugin users need not worry, because all of its data transform features can be used in .layouts.yml files too!
Currently the plugin supports just layout definitions, but the plan is to add support for asset library definitions. Pull Requests are welcome!
Pick and mix
The modules and plugin introduced here can be used on their own or in any combination. The Pattern Lab plugin can be useful on its own just for the pseudo-pattern feature, even for non-Drupal projects.
The modules and plugin can probably also be used for other things not described in this blog post. If so, I would be interested to learn about such use cases.