Single Directory Components with Drupal 11 and Radix 6

Forward thinking with retro visual metaphors

a short light blue guy with a waterdrop-shaped head, dressed in a yellow office shirt, dark gray pants, shoes and tie, happily holding an open drawer on a retro-styled file cabinet with one hand, a yellow folder on the other.
ah, the good ol' days.

the Desktop metaphor is one of my favorite computing concepts. it encapsulates everyday work in a useful manner for people of all walks of life to understand computers in a way that makes sense to them. an elegant solution that dates back to when offices were already an ubiquitous staple of modern life, developed in the 1970s by the Palo Alto Research Center, I studied both its qualities and limitations during my postgraduate course in UX. 

plus I grew up with it so there's definitely some nostalgia attached ;) 

specifically the folder metaphor comes to mind as I revisit a previous post in which I outlined the broad strokes of my website redesign. one of the most important features was SDC, or Single Directory Components: reusable sets of modular functionality, typically comprised of HTML, CSS, and JavaScript. 

(did I say folder or directory? oh well.) 

in Drupal, SDC have some added functionality, such as twig templates and YAML files, aimed at leveraging everything the framework already does well — and if your theme is based on Radix, then so much the better, as that feature is written into it from the start of business. 

therefore, as planned, we'll be reviewing that functionality today. 

the basics

screenshot of a VS Code panel showing a folder named acme-slideshow inside of which several files can be seen with "acme-slideshow" and extensions such as CSS, JS, and SCSS.
neat!

an SDC component can have as little as a single CSS or JS file, but you'll find that the typical reusability comes with a YAML file describing the component and a twig template telling your theme how to build it on the go. additionally, if your theme has been set up to handle SCSS files, the resulting CSS will be readily generated for integration into your pages, wherever the component shows up. 

the YAML file

screenshot of a VS Code panel showing a YAML file. the variable entries "slideshow_id" and "count" are highlighted, along with their nested properties.

basic components don't need this, but it's the starting point if you need more complexity like a twig template or variables. here slideshow_id and count are highlighted along with their properties, meaning what they can store. this will be useful further along. 

the twig template

a split set of two VS Code panel screenshots showing different parts of the same twig file. the variables "count" and "id" are defined at the beginning from existing YAML entries "count" and "slideshow_id", and recalled further down.

in this twig file, variables are defined at the beginning from the existing YAML entries, and recalled further down. we can alter the variable name for readability, as is the case of slideshow_id becoming id, and count may be set with a default, so as to prevent any errors. 

binding it all together: the View

screenshot of a VS Code panel showing a Drupal view twig template with its filename highlighted in the code comment.

everything defined by the component can now be used outside of it: for example, in a Drupal view twig template (check out its filename in the code comment). I have created a view called Acme, with an unformatted list display called home. ergo, the filename is views-view-unformatted--acme--home.html.twig. with the {% embed %} code, my component is placed nicely in the block, which can then be displayed in my homepage: 

a screenshot split three ways, showing three different versions of a slideshow for desktop, mobile, and tablet screen sizes.
and here's the finished feature, in all its mobile-first, separation-of-concerns, layered glory.

with a little bit of front-end collaging, we can see three different versions of the same slideshow for desktop, mobile, and tablet screen sizes. just like in a real bricks-and-mortar office where every professional does part of the work, so too in SDC every file contributes its bit for a picture-perfect component.