 I think we'll get started as people are still kind of streaming in, so that's cool. So this morning we're going to talk about Drupal 8 pattern lab and some front end workflow patterns that can potentially combine the two. Is this better? Okay. My name is Anthony Simone. I'm a developer at a digital agency out of Denver called Elevated Third. And our goals for this talk are going to be to introduce a handful of concepts that will be required for using Drupal 8 and pattern lab together. Review a practical implementation of the two, what kind of problems come up and how we can, or at least one potential way to solve them. And then discuss some benefits and challenges to using this workflow. So we're going to start with atomic design. Atomic design is a methodology popularized by Brad Frost that sort of depicts creating a design system from the smallest pieces first. So every single element of your design system is going to be explicitly defined at the smallest level. He uses the term atoms. And then these atoms will be put together to bigger items, molecules that will then be put together to larger components, organisms. So you kind of repeat this pattern of defining small elements, putting them together to medium sized elements, and then again to bigger elements. And then create over and over and over to create eventually like templates and then full pages. So the kind of crux of atomic design is creating a design system that has reusable components. Explicitly defined components and then reusable components throughout the whole project. So Drupal uses kind of some of these pattern or some of these sort of pieces of atomic design already. In Drupal 7, most of it is in kind of the back end, the data architecture side of Drupal. We have fields which are sort of a combination of definitions that allow you to create a certain functionality on a node or a custom entity. And then field formatters which allow you to take those definitions and then implement them visually or presentationally in a certain way. You can add a field to a content type or a bundle of any entity and that field is available across all the other bundles of that entity. So you've defined one package of items and then you can reuse that package. So Drupal enforces this pretty strictly like on the back end, on the content architecture side of things. Entities are also another pretty good example. You have entities and then you have your bundles. And then view modes are different presentational aspects of your entities, your content types, your custom entities. Paragraphs is another module that if you've used it, essentially creates a custom entity for you to build bundles that are arbitrary groupings of fields. So creating components. All of these are component structures that already exist on the data architecture side of Drupal. However, in the front end of Drupal, there's not a lot of structure that is required to be followed. So a pretty typical workflow for Drupal 7 and probably even a lot of Drupal 8 sites from the front end point of view involves, you have some sort of data architecture defined. You start your site building. You build out content types, your custom entities. You add fields. You add content. And then you have something to theme. You have something to work with. So wherever you are in your project, you may have a lot of definition. You have a lot of site building done. You add in content, you theme. And then you iterate over this loop. As things change, you have to go back to site building. You have to delete fields, add new fields with different settings. You have to add new content types. You have to then add new content that you have access to theme. So anytime you get to the theming part, you're adding your functionality. You have to have done these other two steps. So you iterate over and over and over and over this loop until eventually the site launches, right? So that kind of requires that theming depends on content. And in the development stage, a lot of times this content is placeholder content, right? It doesn't mean anything. It's probably like Laura Mipsum's stuff. You're going to be building out placeholder content for every scenario that you have for your site. So, like, if you have all of your content types, you'll have probably a piece of placeholder content that describes every combination of interactions within content on that piece that you need to handle on the front end, right? So you have a lot of placeholder content in your site. And then theming also occurs within the context of Drupal. So say you have an event, right? An event node. And that's being displayed in a teaser view mode. And you have a form in that teaser. You might want to be theming that form, but the page you're looking at has the form. You have your event teaser. Maybe that's on a landing page. And then you have the region context, the page context, right? You have all these layers of context which are great for some things. But when it comes to theming, it can potentially complicate things. It can make some issues. So this, like, heavily layered context that you work within Drupal, as well as placeholder content, essentially being a dependency for any front-end work, can create problems, or at the very least add time and kind of boring, iterative work that you have to do to get to the point where you can theme. So this is where Pattern Lab comes into play. This is just the little blurb on the Pattern Lab site. At its core, Pattern Lab is a static site generator, either in PHP or Node that stitches together UI components, but there's a whole lot more than that. So let's take a look, before we get to that, let's take a look at Pattern Lab really quick. So we're on the same page. So this is on my local, but this is, if you go to patternlab.io and check out their demo, this is just their demo pulled down. And essentially, Pattern Lab is kind of like a giant style guide, right? So you can see at the top, you've got some menu categories, which are the terminology that Brad Frost uses. You have atoms, molecules, organisms. And those are displayed just in order from top down. And it's sort of like a style guide, right? You have your color definitions, your font definitions, your heading definitions, things that might kind of be like fields in Drupal. And this is just without, totally without the Drupal context. This is just a vanilla Pattern Lab project. Image definitions, right? You have all of your tiny, tiny component definitions. And if we scroll down a good bit more, we start to see some pieces that are adding more of these together. So we have like a component with a title, a body, and an image. And you can trace all of these back up to where they were defined, like at the top of this document. And then let's take a quick jump. So this kind of builds all the way out into the page level from like Brad Frost's idea. So we can look at the home page, which is like a wireframe version of a home page, right? Built with all of these components that we've defined. And then we can also look at like a page, a version of the home page with real content, maybe. Well, okay. This one doesn't have that, I guess. But we'll get to a real version in the future. Anyway, just wanted to give an overview of that. So we're all on the same page of what Pattern Lab is. This is just like the looping video that's on the Pattern Lab website, and it kind of gives you a visual representation of how Pattern Lab works, how you kind of use it to build out all of your content. So when it loops back around, you can see we start with atoms. So a label, an individual input, a search button, those are all atoms. They come together to build a molecule, which is maybe the search form. It goes in the header, the header goes in the template, and then the template fills out with content, right? So that's just an example of how you get from one atom, one tiny defined component, all the way up to the page level with Pattern Lab. So Pattern Lab kind of provides two purposes. You have Pattern Lab as a design system, and then Pattern Lab as an implementation. So if we look at Pattern Lab as a design system first, it gives you a context to build pattern-driven UI interfaces, right, with this idea of atomic design. It sort of forces you to use these patterns that Brad Frost built up in the atomic design methodology. You must define all of your tiny elements first, right? All of your bigger pieces depend on those, and you're including those into your project. So it forces you to create consistent and explicitly defined building blocks, and this is really important as we get a little further down, and I'm sure everyone who's worked on a project that has had any longevity consistency can be hard, especially when there isn't much, right? Your theme on a project can be maintainable if you can implement some sort of consistent structure. It also gives us some semblance of documentation across all teams on the project. So depending on what your specific workflow might look like and what your team looks like, that might be developers, designers, UX people, account people, and the client even, right, as a whole part of the team. So it gives you a visual and linguistic representation of all of your data structure, which can be pretty useful. So then if we look at Pattern Lab as an implementation from the development standpoint, as we said before, there's a PHP version and a Node version. It's pretty tool and language agnostic. It's pretty flexible. You can take care much about other things. You can use your standard workflow, right? You can have like your gulp workflow for assets if you want, whatever you normally use in your normal projects. It's pretty flexible also in terms of templating language. There's a lot of plugins that already exist for it, Mesh Dash, Twig, Handlebars, and if you use some other templating engine that doesn't, you can implement it if you so desire. Like if you've got the dedication to do it, then you can use it with any templating language. So it's pretty flexible. And it has some extra tools in the UI that just gives you some extra pieces, like a viewport size, annotations, et cetera. So moving into how this actually works from a development standpoint. So as we said before, like from the methodology point of view, we're creating our small templates. We're defining these small pieces, and then we include those into larger pieces, right? Our larger building blocks. So from a development point of view, we're using whatever our templating engine is, Twig in this example, because we'll get further into this and talk about Twig with Drupal, where we have our Twig templates and we're including those smaller Twig templates that we've defined, and it's backed by sort of a JSON data object. So if we look at that demo project that we had in the browser and kind of just look at a couple example files so we have sort of an understanding of how these templates work, we've got Twig templates backed with JSON files. So for example, we've got a byline template and if we find that in our front end just so we have a good idea, let's jump back over to our style guide, text, it's under here. Looks like this is depending on something from the internet. Okay, sorry. But let's go back to our view hall. Sorry, having a hard time finding it. Anyway, we have our byline template. So all it's doing, you have some markup around it, by author name, first name, last name, right? This content is being supplied by a global data object, data.json somewhere else in the project, and it has all of your global data that you have access to so we can look down, we have an author variable in first name and last name, right? Then if we want to include a new template that depends on that byline template, like a new version of byline with different content, all we need to do is use default Twig syntax to include our molecule byline template and then pair it with a JSON file with the same name that has different content. So we have first name Anthony, last name Simone, and that's going to give us a new template that has the different data. So we'll take a closer look at more examples when we get to the Drupal part, but I just want to make sure we're all kind of on the same page about the structure of how pattern lab works. You have template JSON file pairs. So from the high level point of view, this is what a pattern lab project's directory structure looks like. We've got the source directory, which is the most important here. This is what we're going to talk the most about. This is where anything you're going to edit is going to be, so all of your templates, all of your JSON files. And then we have some other items that are a little more relevant to the pattern lab project. We have core, some dependencies, that kind of thing. We're not going to focus too much on that during this talk. So now we've got some of the basics, atomic design and pattern lab. This is our gold standard. This is what we're trying to work towards in this project. We want to maintain a Drupal 8 project that implements pattern lab. And ideally, we want to have a single source of assets for our Drupal 8 project and pattern lab, and they should be identical. This is what we're going to work towards, and we'll see if we can get there. That way we can work with our Drupal 8 projects just as we normally would, and we can integrate pattern lab in some fashion. So just taking a step back briefly, pattern lab in Drupal 7 would be a little bit of a pain to maintain, probably, right? We've got these two things that are two totally different projects. They don't really overlap that much, because in Drupal 7 we had PHP template that wasn't really able to integrate into something like pattern lab, as it didn't have a lot of the features that other templating languages would have, like, extends, and things like that. So we had a pattern lab project, and we would have a Drupal project. And if we wanted to try to keep these two assets pretty similar, it'd be a lot of manual work. We'd have to build out those templates in pattern lab to look like the markup that we know Drupal's going to give us. So we'd be building two projects and maintaining two projects. And that seems pretty rough. Like, that doesn't seem great. You probably would only do that if this sort of asset was like a big sell for the client, and you were specifically building this project. You wouldn't just slip it into a project and use it on the dev side, because it'd be a pretty big time investment. However, in Drupal 8, as we kind of all know at this point, we're using Twig. Twig is the templating engine for Drupal 8. All templates in Drupal 8 are Twig templates. The .twig extension. And so this gives us, like, a bridge, the possibility to use these two projects together, right? Pattern lab has a twig integration. Drupal 8 uses twig. So now, theoretically, we can do this, right? So we know that we can do this. Now we have to go over some of the issues that we need to, like, break through to actually implement it. So we're going to start with some of the high-level problems that present themselves integrating these two projects together. So a vanilla pattern lab project just implements whatever chosen templating language you're using with pattern lab. There's no really extra assumptions. So this means you would build out your vanilla project with includes and extends or whatever syntax your templating language uses. So, for example, you might have some component that's a product teaser sort of thing. You have some markup, you have your main templates that you've defined. You have your Adam's title, some image style, Adam's body, molecules, details, right? So those are all going to be things that you've already defined in pattern lab and you're including into your template. So if you're looking at this and thinking, okay, that makes sense, but this doesn't look like my Drupal templates look like in Drupal 8, right? I'm not including field definitions directly. You're right. That's not how Drupal 8 uses twig. That's not how that works. So we're going to have to find a way to bridge sort of twig's default implementation with Drupal's implementation of twig. So we're going to try to find a way to fix it. But that kind of seems pretty hard, right? I mean, it is. The twig syntax, like include some template file, is definitely not the same as render some string, right? Twig print strings. So when twig sees the double bracket syntax, the render syntax on content.field title, it expects that to be a string. Whereas the include syntax is including a separate template, right? So essentially, we need to be able to make render some string work the same or similarly as including a template if we want to include pattern lab and Drupal. So this is the big problem that's in our way. And fortunately, some really smart people have already thought about it and kind of put together a solution. So Alexi Peebles developed a plugin for pattern lab called the data transform plugin that's specifically a solution for this problem for Drupal. So essentially, like we looked at earlier, the twig templates in pattern lab all can exist in a pair with JSON templates with the same name. The JSON files feeding the twig templates data, right? So the data transform plugin is leveraging this JSON twig duo to include content in a slightly different way. So the data transform plugin provides us a series of special keys that we can use in our JSON files. We'll go through each one a little specifically, but it gives us attribute, include, and join. And so if you've done a bit of templating work with Drupal 8 already, you know that Drupal 8 uses this attributes object. You can create it in PHP. You can pass it along. You could add classes to it in twig. But it's like a specific implementation, right? It's not just a string. So we have to know how to handle that. And this key allows us to handle that in the JSON files. The include key allows us to directly include another template defined in PatternLab. Because as I said before, we're expecting content.fieldname to be a string when we're printing it out. So that include key, when it's used, we'll go look for another template, stringify it, and pass it along. And the join key allows you to do that from multiple templates at once. So this kind of allows us to use render content or render content.fieldname as we would normally use in Drupal but link it up with PatternLab. So we're going to go over each one of these with specific examples. So it's a little bit more clear. So these are kind of stripped down versions of what these templates and JSON files might look like. But you can see in the twig file, this is used all over Drupal, like just printing out the attributes object there. And then in the JSON file that you'd have in PatternLab, you would back it up with your attributes variable. So that first piece is just normal JSON, right? Your attributes key. And then you're using the special attribute key, which essentially knows how to handle everything below it. So you can pass it classes, right? Data IDs, regular IDs, and it takes all of that content, turns it into a string, and then passes it back up to PatternLab. So it knows that rendering attributes means render this string for me. The include key is pretty similar. So we have some generic article. We're printing out our label, and we're printing out content.fieldProfileImage, right? So if we go up and look at our JSON, our label key pair is defined. And then we have content and fieldProfileImage defined. And inside that, we have the special include key that's selecting a pattern that's already been defined for the PatternLab project. So what that tells PatternLab is, hey, go look for the elements profileImagePattern. Render that, however it's defined, with whatever data it has defined for it, and then give it back to me as a string. So when you get to the template's point of view, content.fieldProfileImage is a string, and it just renders that string. Join works in pretty much the same way, but you can pass multiple elements together, and it ties them all together into a long string. So the join keyword here, this is maybe like part of a page template. You have your region content bottom, and then in this example, maybe multiple blocks that are printing out like featured events, upcoming events, past events. All these are defined in PatternLab, and the join keyword says, okay, go grab me all three of these blocks, turn them into a string based on their configuration, and send that back up as page.contentbottom. And then our twig template down here renders page.contentbottom as a string. So that solves the big issue of getting these two pieces to work together, but we still don't have an actual practical implementation yet, right? We just theoretically think it will work. So now we're going to go through some of the specific details that need to get us through from theoretical implementation to practical implementation within a project. So just as a side note, last year at DrupalCon, there were two talks that were pretty relevant to PatternLab. They're both super great and totally still relevant. If you're interested, I'd say take a look. And they take different approaches than from what I'm going to go through. So form one did a talk, phase two did a talk, and then Alexey Peoples also has a PatternLab theme for Drupal. All of these take different approaches. So definitely go through some of these other resources in an interesting concept, but maybe my approach doesn't work for you. So now we're going to go through each of the kind of individual technical challenges, and we'll talk about the solutions that I implemented, at least, to get me through to a functioning tool at the end to have PatternLab and Drupal8 work together. So the first issue is project structure. And it's pretty simple, right? It's like where should PatternLab live and how should it work? But this is kind of one of the high-level questions here. For me, it made sense for PatternLab to live in the theme root. So that's kind of the context that the rest of this is going to take. And then we're going to figure out how to make it work within the theme root, how to stitch everything together and make everything aware of what it needs to be aware of. Another sort of issue is that really there's two versions of twig in play, right? Drupal is using one version of twig. It's being defined in its composer.json file pulling in all of its dependencies. PatternLab is using a different version of twig. So there's potentially a couple ways to think about this. Maybe we want to try to include everything together into one set of dependencies or keep things separated. I didn't really want to include them together because I felt like our main project that's going into production shouldn't depend on PatternLab in any way. For instance, maybe PatternLab has to restrict the version of twig it uses to some older instance, for example. Then that would also have an effect on Drupal, right? Which shouldn't be a dependency. So taking that into account, we need to figure out how to get these two implementations of twig to work together without hacking either project. We want to be able to update as easily as possible. We don't want to depend on some custom patch or some custom hack to get them to work together. So we're going to try to work with what we have. So here's kind of an outline of the issues. We have Drupal8 twig and we have our PatternLab twig, right? Our Drupal8 version of twig finds templates anywhere in the Drupal theme. Right? We don't find templates anywhere else. So if you have custom modules defining templates, you need to hook them into the theme system, right? You need to tell Drupal about it. But any template in your theme route Drupal will know about. The PatternLab version of twig only recognizes templates within a certain structure within PatternLab. The Drupal version of twig, it recognizes twig files, but it only recognizes whereas the PatternLab version of twig will recognize any file with a .twig extension which includes .html.twig. And then finally, based on my previous sort of assumption, our PatternLab project is going to be inside our theme. So this kind of sets up our problem that we need to solve. This is our given for this scenario at least. This is just a generic theme setup, right? Theme kits, the name of the theme. So whatever your theme is. And your theme may look very different. But you have some of your theme assets maybe use Bauer, maybe use Node. You have some of your theme files down at the bottom, the libraries.theme.info file, your asset folders and then PatternLab just sits right there. It feels like a theme asset, so it feels like that's where it should live. So given that PatternLab is inside of our theme route, we need to solve these problems. So PatternLab is not aware of the templates outside of its project route, meaning anything in our templates directory. Drupal is aware of all templates inside the theme, meaning everything inside of PatternLab. And ideally we want to go back to that like gold standard. We want a single source of truth for all of our assets, otherwise we're setting ourselves up to have either a complicated tool chain or possibly a lot of extra work. So we really only want them to exist in one place. And we don't really want our template directory to be somewhere we wouldn't expect it to be, right? Like maybe this is the structure of my theme for almost all of my themes on my projects. I don't want to suddenly move templates to be somewhere hidden or strange or somewhere my co-worker wouldn't expect or somewhere some other person in the Drupal community wouldn't expect. So the solution that I used for this problem was to just use sim links. So essentially all of your directories in Drupal that have folders that have templates that you need to reference in PatternLab are just going to be sim linked over. So for instance we've got our PatternLab source directory on the left and our theme route on the right. We've got our templates directory and this arbitrary grouping folder which is Drupal templates on the left and each template directory from Drupal is sim linked over. Block, field, form, layout, etc. And then you can see at the very bottom we've got two items that aren't represented on the theme side and so you can include items that have templates from custom blocks, right? You can include templates from Drupal that might be thinking looking at this while Drupal has this hierarchical inheritance based templating system, right? What about all the templates from Classy that I'm inheriting because my theme is a sub theme of Classy? So that's true. You're going to probably have some a little more explicitly defined templates than you otherwise might. So for instance even if you're not changing the Classy node template you're going to be able to recognize it. So I want to use some specific examples to describe what all these templates are going to look like. So we've been talking about Drupal templates, pattern lab templates, the JSON files. It can be a little confusing. There's a lot of different syntaxes involved. So we're going to take an example that might be like a news teaser and look at where it exists in your Drupal template or in your Drupal project and see how all that's tied together. So here's our node news teaser template. And this lives just where you would expect it to be in your Drupal project without respect to pattern lab at all, right? You might have your theme, templates, node, and then all of your node templates. So we've got our node dash dash news dash dash teaser.html.twig. That's all standard twig stuff, right? And this template is slim down for ease of reading stake but essentially the classy node template by default, right? We're setting some of our default classes in the classes variable up top. We're adding that to the attributes variable in the article and then we're printing out some content. So this is pretty standard Drupal.html.twig file. So once we have this created and we want to include it in our pattern lab project, we have the corresponding pattern that we created as news dash teaser dash twig inside our patterns nodes news directory. So that's just a hierarchy in pattern lab. And all it's doing is extending or including the template that lives in Drupal, right? So this Drupal template that we created in the normal way we would create our Drupal templates. We're just including that and then providing a JSON file with the same name so news dash teaser dot JSON that supplies us all the data that we need. So if we go back and take a look again, we've got that attributes variable and we're taking advantage of the attribute custom key that the data transform provides and we're just defining it so it exists when it gets to here and we're adding the classes in the twig template. We've got some of the helper variables like node dot bundle and the view mode variable defined here and we can jump back and take a look and node dot bundle is pretty typically used to add like your bundle class view mode is the variable used to add your view mode, right? So we're just providing all the standard variables that that you're expected to find in your Drupal templates and essentially that's all you need on the pattern lab side. So you've created your Drupal template in exactly the same way you normally would create it and then you've just provided the data, right? Because pattern lab isn't depending on any data in Drupal, it's only depending on the JSON data that you're providing. So this brings up a couple of potential issues. So the join keyword and the include keyword allow us to include templates of strings, right? And that allows us to use these two pieces together. However, that means you need to either use the content variable with the join keyword for all of your elements inside a template or you need to explicitly define each content dot field name because we either have to choose let's make content the string we're printing out or let's make content a variable and we're printing out strings that are content dot field right? Content dot the item in the content area. So for instance in our template here we're explicitly printing out content dot field date and content dot field link even though we don't need to right? If in a normal Drupal project if there was no markup around those you wouldn't print them out explicitly there's no reason to you just print out your content variable but in our case we kind of have to choose one or the other because the without filter that you would normally use to hide fields is sort of just a stub in pattern lab. It doesn't have the same functionality because pattern lab isn't doing all of the work that Drupal is doing with that filter. So essentially you just have to choose one or the other in terms of a pattern. So it's not totally ideal but it's a relatively small concession to make at this point. Just a side note to point out any custom filters or functions that you have in your project is that you don't have a pattern lab as well. So if you're using the Drupal default pattern lab implementation most of the functions and filters that are custom to Drupal are already defined as stubs but if you add new custom ones you just need to go in and add them as stubs. It's super easy. I'm not going to jump into it but you can find an example in the twig components folder and just copy that. So if a function or a filter defined it can prevent pattern lab from compiling and not always give you a useful error message and it can be a really painful thing to debug. So this is just one thing to keep in mind. And another issue is that pattern lab is a static site generator so you change one or two things and you have all of a sudden hundreds of new files, right? So messy repo. And my solution was just ignore the public directory which is the compilation target and create a publish directory add some sort of gulp or grunt task that just copies over your public directory so you can essentially publish like iterations of your style guide when you want to. And you can commit all of those together in your repo and it's nice and clean. So now we're going to check out an actual Drupal 8 implementation and look at the Drupal 8 site and look at pattern lab a little bit before we jump to some conclusion pieces and hopefully I have some questions and stuff to talk about. So we built a Drupal 8 site for youth on record which is a Denver local non-profit that works with local youth in music education. Let's jump to the site really quick. We've got we're just going to kind of take a look at the home page just as an example we've got things that you typically expect to see, right? A header, we've got menus, we've got the home logo, the slider, in the header a handful of components so like this site leverages paragraphs if you're familiar with that module and then a footer, social links, more menus, right? Pretty standard structure. So if we jump over to the pattern lab version of the project we can see our beginning, our introduction to the project, the pattern lab project is very style guidey, right? Style guide, like definitions, colors, fonts, icons, headers, some specific header combinations and then we're starting to define things like WYSIWYG fields or WYSIWYG styles and individual fields and we're dealing with all those tiny pieces, right? And then if we jump over to our paragraphs overview we can see an example of, scrolled up, these are all of our paragraphs components, right? Which are just arbitrary groupings of fields but using those defined atoms that we created initially, right? So we have a text area and a link and then in our next area down here a text area and a link and these could be the same text area component possibly that you initially defined but because it's in a different context you have different contextual theming, right? So this is presenting all of the markup you'd expect to see in Drupal for this paragraph bundle with only the context of that paragraph, right? This is that paragraph's wrapper and everything below it but nothing above it. Which is what kind of forces you to think about this in terms of component based design. And just we can scroll down and see a couple of the other components that are built in the same way, right? Each one of these items, each one of these fields has an atom at the very bottom level that has a definition and each of these components are like powered by a single JSON file that determines the content. So if we jump back over and return to our sort of gold standard that we started with we've kind of achieved a lot of these things at least, at least the most important ones. We're maintaining a Drupal 8 project that implements the pattern lab and we're using the same assets, right? And so if we jump back to our Youth on Record site we're looking at the home page and if we look at the pattern lab version and check out the home page template built out here it looks pretty much exactly the same, right? We have all the same functionality that we had on the home page we have the same menus the same content blocks and footers and it looks the same because it's using the exact same style sheet the exact same JavaScript file and the exact same template files, right? And that's what we really wanted to target with our implementation because that's going to make it easy to maintain and easy to continue to use this in the future. When you have a new paragraph bundle or a new content type all you need to do is add that single JSON file that describes the implementation of that component and then boom, it's in your pattern lab project. So we have single source of truth and we have an identical state of assets between the two projects. There were some maybe not 100% ideal things like being more explicit in some of our definitions inside of our templates, copying over some templates that maybe aren't actually changed but those feel pretty minor compared to the benefit we have and the way this all kind of works together. So I wanted to take a little time to kind of talk about some of the benefits and challenges that this sort of workflow presents because theoretically it can be pretty interesting but practically it can create, it can offer some cool benefits but it can also be difficult to maintain. So I feel like this is kind of a polarizing idea or a way to think about theming in Drupal so it wouldn't be surprising if at this point a lot of people either feel kind of strongly one way or strongly the other. Like some people might be thinking like yes, this is how I want to theme in Drupal, right? This is all separate from the back end. I don't have to worry about dependencies that feel like inappropriate. Like count me in, this is great. And these are some of the benefits that I think a person from that perspective is probably thinking about. This offers the potential for a decoupled workflow and decoupled in this sense means your front end workflow can be totally separate from Drupal. So you can build out all of your templates, all of your theming and functionality with JavaScript if you want to before a single field is added to Drupal, right? If you have enough of the knowledge about how twig works in Drupal and how your templates are going to be built you can write out your templates pretty confidently and then when data structure changes and data architecture changes a field name has to change or a field type has to change all you need to do is change one string in your template. Oh, this needs to be field roles instead of field role instead of deleting the field, adding the field, pushing up the config adding the content that needs to be added in all of your sort of demo pages, pulling everything back down, right? That seems a lot faster. You can actually do all of your theming outside of Drupal if you wanted to or a very large amount of your theming at least. It creates a pretty flexible project workflow so kind of borrowing from that first point if there's a bit of a blurry line between data architecture decisions and implementation or design and if kind of things are happening all at once, you don't need to necessarily have all of those decisions made. You can work ahead without really losing time because you don't have to go back and refactor those fields or content types within Drupal itself. This using pattern lab in this way sort of makes you think about a componentized structure for your theme assets in a bit of a strong way because you might do your best to do things like let's only target content types and view mode classes to keep styles componentized or paragraph wrapper bundles or whatnot. But if you're using the pattern lab project to actually do your themes, you don't have that extra context, right? It's not even available to you. So it kind of makes you think about where's the responsibility for this CSS or this JavaScript coming from? Does it really belong to this paragraph bundle or is it related to the field that's implementing the paragraph or maybe actually the content type that the field's on, right? It forces you to think about these items which you may already be thinking about but it kind of makes you do it. You get this giant style guide, right? And because none of the data in your pattern lab project depends on Drupal, it depends on this static JSON file, as soon as you add a single version of a component to your pattern lab project, it's there forever, right? So you have this static style guide for your entire project that can be maintained with minimal effort and that can potentially be a great asset depending on what the project looks like and what the client looks like and what the client needs and testing kind of sort of, like you have this style guide, right? So if you have these interactive elements on a component or on a content type and you need to add a new version, you can test visually against the other versions you have existing to make sure your new styles or your new scripts aren't going to break any existing components or existing theming on your site. So it's not real testing, right? But it provides a pretty quick visual regression testing type of scenario compared to, oh wait, I have to build out every item on my local that has all these combinations of things because they don't exist on production anymore because the client deleted all the demo content, right? So that can be pretty useful and communities. ParentLab has a pretty big community, Drupal obviously has a big community, there's already been a lot of people that put a lot of work into allowing these two things to work together so that's pretty great. Then there's the other side that maybe feel like this is pretty different, this is a big departure and possibly like, I don't know about this, I don't want to deal with this, it sounds kind of like rough, terrifying, I've got a lot of issues. And I think there's a lot of really valid issues for that kind of point of view. So time is probably the first one that would come up, right? How much time does this take to implement? How much extra time does it take to maintain? All of those kinds of questions and issues and they're totally reasonable, right? Because project timeline and budget is a big thing when it comes to actual implementation of a tool like this. Definitely the first time someone uses like this sort of setup there's going to be a learning curve. But with medium to large size projects or projects that are maintained pretty aggressively over a long period of time, I feel like you can reap a lot of benefits from some of those things that ParentLab provides that we just talked about in the previous set of slides. So there's more tools, right? There are a lot of tools. And for some people these could be a lot of new tools. You have to use Composer. Maybe you're everyone's already using Composer in Drupal 8 or at least starting to get familiar with it but you have to manage ParentLab with Composer. Some PHP in the command line. You're probably going to be using Node and Gulp to do some more task running if you're not already using that in your front-end workflow. You have to understand ParentLab, how the data transform plug-in works, how JSON works. You have to understand Drupal pretty well. How Drupal uses Twig, how you're going to expect to see templates rendered from Drupal. Then you have all of your standard bits, right? Your HTML JavaScript, your CSS. And the big issue could be debugging any combination of these, right? There are a lot of potential new places for there to be issues. So there are a lot of tools and using this workflow does require kind of understanding a lot of these pieces. Is it too many tools? I think that's kind of a question that depends on your situation, right? What's your workflow look like? What's your company's workflow? Your team workflow look like? What are the resources you have on a project? What do your team members look like? How strong or difficult of a workflow can be distributed across all of the members of your team, right? These can be some pretty difficult issues to get past, potentially, depending on what this looks like for you and your team. And then I think this last piece could be one of the most or the biggest roadblocks or one of the most difficult things to overcome. But what does the end-to-end project workflow look like for your company, your team? Because the biggest thing, like Pet and Lab provides some useful things for the developers, but if it's only providing those things to the developers and not to the client and to the design team and as a static point of reference and documentation for the entire project, you're losing out on a lot of the benefits that it can't provide. So what is your project workflow look like? Can you make changes into that? Or can you make changes to that that allow you to leverage Pet and Lab and what it offers? And those can often be big changes and not easy to implement. And just a couple, like housekeeping bits. I've got just some resources. If there's items you wanted to check out a little further and then kind of just a slide at the end that if you wanted to get all this set up on your local, you can go through this and you should be pretty much running. Some housekeeping contribution sprints tomorrow. Don't forget. Oh, not tomorrow, Friday. Thanks for coming. Any questions? Hi, thank you very much for your presentation. Hi. Do you have anything to say about the components module? About paragraphs? Components. I don't know the components module, actually. It's a module on Drupal.org that provides to make it easier to work with things like Pattern Lab. Cool. I'll check it out. Thanks. Just a question about process. When you do this approach, are you theming to classes that are generated in Pattern Lab? So I would be theming to classes that are generated in Drupal because you're providing all of the data. If you're generating all of your classes in your patterns, which is like Pattern Lab, then you're generating all of your classes based on whatever data you provide it. So you can provide your Pattern Lab project all the same data that you're going to be getting in Drupal, so all of the classes will be the same. Okay. I was wondering what your solution is to including module assets into Pattern Lab. So for that, you can add any custom CSS to the Pattern Lab to the header. For example, with video embed module, they have a tiny CSS file for responsive video stuff. So there's a few manual steps like that. And for that case, I just added a CSS link in the header to the Pattern Lab file to include any other asset dependencies for modules like that, external things. So there is some housekeeping to tie together because the only direct asset that you're sharing is that main theme file, including CSS or JavaScript file. Hi. I don't have a question for you, I just have a quick comment. I would just like everybody to remember that while we're going to our other sessions that there are still people that are here trying to hear what's going on so if we can keep the volume a little bit low. Thanks. Thanks for the presentation. Where can we find the resources and presentation and the sample project that you mentioned at the end? If you can go to the session page and there will be a link to the slide deck and the whole slide deck is public. Thank you. Hi. Question about the overall demo that you had for all your slides here. This is for a single site implementation, is that right? How have you tackled one single source of truth with Pattern Lab but across multiple sites, multiple properties? They still want to be consuming the design system? I think that would depend a lot on what your requirements for your Drupal structure is going to be. Is it multi-sites? Is it totally separate projects? Are you sharing things across those projects like CSS assets? That kind of stuff? Maybe you can potentially create a Pattern Lab project that is all of your shared assets, shared structures that are distributed across multiple projects. But does that scale? I think so this implementation by default wouldn't necessarily scale for a multi-project setup, but I think depending on what your needs are you could adjust how this is integrating with your projects and potentially make something that does. Okay. Thank you. Looking at some of the documentation for Pattern Lab, there is this feature called Pattern States. Do you know if the Data Transform plugin affects the use of that feature? Do you mean the states approved? Right. I didn't implement that feature on this project specifically, but I don't know the answer, but I would guess that it doesn't. But that's only a guess. I tried it on my side and without includes I think Pattern Lab acts kind of funny with some of those things. I was curious if you knew about it. It is using a different structure, right? It's using this to kind of supplant the way Drupal thinks about content. So there could be some default kind of inheritance things in Pattern Lab that do break. So it wouldn't be surprising. I don't know. I don't know what to do though. Hi there. Thanks for the presentation. I was wondering how designers sort of fit into this. Do they still do in your instance, do they still do Photoshop templates? How do you talk to your designers in terms of designing in this sort of methodology? Yeah. So in this project specifically if you're more standard across projects then you could adjust the way you interact with design or when does design happen in a project or can we do some quick prototyping of things but then we have all those assets still that we can leverage, right? So I think that goes into that last sort of con slide being there's a lot of things that this can provide for a workflow but that's also a lot of solutions to come up with, right? Or a lot of changes maybe some existing workflows and patterns within your company or within your team. That's I think a big part of finding a good and useful implementation of this. I'm curious about when you actually start with the Drupal templates or when you build those I've always sort of started with pattern lab and done whatever I want to do in pattern lab and then kind of work towards the Drupal implementation. It seemed like you had a lot of very like opinionated kind of Drupal templates. How do you when do you build those and how do you do it such that you're not like forcing such that the pattern building can still be kind of fluid? So my context in how I work with Drupal is that I'm definitely a friend and developer but I do a handful of custom code and I'm pretty familiar with what Drupal templates are going to look like or what some of that higher level structure is. That was very useful in terms of building things out without necessarily having that in place yet. So that kind of background was really helpful but starting with the small pieces starting with field implementations getting everything built out for forms for instance because a form in Drupal if you have a radio button the input is a template the label to the input is a template the list grouping is a template then you have another one that wraps that with another label so like it gets pretty deep but I think starting with the basics if you're wanting to be able to build from the ground up like this would be really helpful because when you get to the bigger pieces you're just including things right? You've already created the themes related to like these smaller components and you're looking at the bigger template and you're just including those other pieces so a lot of the work went into the smaller items the initial like atoms and molecules if that answers your question a little bit So from the very beginning you're looking at like a comp or something and you say oh this is a Drupal this is a Drupal field as opposed to this is a pattern lab Yeah so I would usually be taking the content architecture point of view from Drupal so like before I would start with this even if I wouldn't do site building I would have a pretty built out data architecture plan for nodes, entities fields that kind of stuff I think even if that changes in the future having a pretty well built out plan for what you're looking at initially is probably pretty necessary for exactly those reasons Cool thanks Thanks for the questions Thanks for coming