Today, we’re excited to announce the first stable version of our new Component Theming tool, Mannequin. We’ve been working on this for months now, and couldn’t be happier with the progress we’ve made.
Why we built it
When we set out, we had a simple goal: we wanted to be able to do theming work on Drupal Twig templates before the content types backing them were fully built. Like many others in the Drupal community, we turned to Pattern Lab as a possible solution. Pattern Lab was effective at pumping data into our templates, but it turned out to be a pain when incorporating it with Drupal - requiring workarounds for accessing the pattern templates from Drupal and adding complexity to the repository since it can’t just be added as a composer dependency. This makes sense - Pattern Lab is built to be a standalone application that takes ownership of your templates. Pattern Lab patterns are meant to represent repeatable HTML snippets, and the primary purpose of allowing a templating engine (rather than just using static HTML files) seems to be promoting reusability of HTML within other patterns rather than reusability of the actual template within an application.
At some point, it became apparent that the problem we were hitting is one that a lot of people are wrestling with right now… as an industry we’re moving toward bigger, more sophisticated user interfaces built out of a lot of different components. On top of that, the divide between the front-end and back-end is growing larger. Full-stack developers are increasingly hard to find, as complexity on both sides increases. What we needed was a tool that drew a hard line between the front and the back end, but would allow the two sides to integrate without additional work.
What it is
So we created Mannequin! At it’s core, Mannequin is a template viewing system. You tell it where your templates and assets live on the filesystem and what assets you need, and you start development. As you work, you enrich your templates with some metadata that describes them to Mannnequin. Using that metadata, you can pump sample data into the template, which allows you to see how it will look under various conditions. By using the Mannequin UI, you are able to focus on one template at a time, ensuring your styling remains targeted. If all goes well, there should be no further work to do to integrate your styled “component” template into the framework or CMS you are using, since it already lives wherever it needs to within your application.
How it’s changed things
Over the course of developing this tool, we’ve found it changing the way we work. Once you have the ability to visualize your application’s “components” in one place, it becomes much easier to refactor and adjust individual pieces. We’ve found ourselves thinking in terms of “components” rather than pages on the site, and it’s pushed us to isolate and decouple the composite parts of a page, making each component better. This isn’t a new idea, of course… programmers have been thinking this way since at least the 1960’s, and it’s shown up in the theming world via the OOCSS, SMACSSS, and BEM methodologies, as well as Atomic Design. What’s different (for us) is that now we have the tooling we need to apply these concepts across a broad array of PHP applications in a flexible way. We should mention that the only organization scheme that Mannequin imposes is that there is a 1-1 relationship between a template and what shows up in Mannequin as a “component”. Other than that, you are free to use whatever filesystem, CSS, or Javascript structure works for your team.
So that’s Mannequin, in a nutshell. We’re excited to hit a stable release so we can finally start tapping into our backlog of bigger features we have planned for this tool in the future (Live reload, WordPress and Laravel support, Visual regression testing, the list goes on!). We hope you enjoy it, and please let us know if everything doesn’t work out perfectly for you! If you’re interested in receiving updates as this project develops, join our mailing list below.
