DrupalCon Baltimore 2017: Atomic Design in Drupal 8: Isolating frontend workflow with Pattern Lab!

morning everyone I think we'll we'll get started as people are still kind of streaming in so that's cool but so this morning we're going to talk about Drupal 8 pattern lab and some front and 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 3rd 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 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 it 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 atom and then these atoms will be put together to figure 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 again to bigger elements and you iterate over and over and over to create eventually like templates and then fold pages so the kind of crux of atomic design is creating a design system that has reusable components explicitly design components and then reusable components throughout the whole project so Drupal uses kind of some of these patterns are some of these sort of pieces of atomic design already even 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 our custom entity and then field for matters which allow you to take those definitions and then implement them visually or presentational e in a certain way right you can add a field to a content type or a bundle of any entity and that fields 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 or 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 right 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 right 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 seem right 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 lorem ipsum 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 write 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 seaming that forum but the page you're looking at has the forum 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 it can make some issues so the this like heavily layered context that you work with in 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 seem so this is where pattern lab comes into play this is the just 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 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 pattern lab dot IO and check out their demo this is just their demo pool 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 you're 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 a future anyway just wanted to give an overview of that so we're all in 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 and individual input 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 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 build 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 like your 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 like 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 like the development standpoint as I said before there's a PHP version and a node version it's pretty cool and language agnostic it's pretty flexible it doesn't really care much about about other things you can use your standard workflow right you can have like your golf workflow for assets if you want whatever you normally use in your normal project it's pretty flexible also in terms of templating language there's a lot of plugins that already exist for it mush - twig handlebars and if you use some other templating engine that doesn't you can implement it if you're so 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 sizer annotations etc 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 Thunder here or absolutely this is depending on something from the end okay sorry but let's go back to our view all sorry having our time finding it anyway we have a 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 jot json somewhere else in the project and it has all of your like global data that you have access to so we can look down we have an author variable and 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 by line template and then pair it with a JSON file with the same name that has different contents 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 work you have template JSON file pairs so from the high-level point of view this is what a pattern lab project directory structure looks like we've got the source directory which is the most important here this is we're going to talk to 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 they're a little more relevant to the pattern lab project we have for 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 basic atomic design and pattern lab this is our gold standard this is what we're trying to work towards in this in this project right 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 right um this is what we're going to work towards and we'll see if we can get there that way we can 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 share they don't really overlap that much because in Drupal 7 we had PHP template that doesn't wasn't really able to integrate into something like pattern lab as it didn't have a lot of the features that the templating languages would have like extend 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 mark-up that we know Drupal is going to give us so we'd be we'd be building two projects and maintaining two projects 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 is 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 or twig templates the dot 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 group elate 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 um so this means you would build out your vanilla project with includes and extends or whatever syntax your templating languages use so for example you might have some component that's a product teaser sort of thing you have some markup you have your main and your details on the side and you're including other templates that you've defined you have your atoms title some image style Adams 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 Twigg that's not how that works so we're gonna have to find a way to bridge sort of twigs 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 I'm content dot field title it expects that to be a string um 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 live in 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 let's see people developed a plugin for pattern labs 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 and pattern labs 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 attributes including joint and so if you've done a bit of templating work with a tuple 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 pattern lab because I as I said before we're expecting content dot field name 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 Templar 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 field name as we would normally use in Drupal but link it up with pattern lab 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 right just printing out the attributes objects there and then in the JSON file that you have in pattern lab you would back it up with your attributes variable so that first piece is just normal JSON write 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 um regular ids and it takes all of that content turns it into a string and then passes it back up to pattern lab 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 field profile image right so if we go up and look at our JSON our label key pair is defined and then we have content and field profile image defined and inside that we have the special include key that's selecting a pattern that's already been defined for the pattern lab project so what that tells pattern lab is hey go look for the elements profile image pattern 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 templates point of view content dot field profile images will 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 pattern lab 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 content bottom and then our twig template down here renders pages content bottom is 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 like theoretical implementation to practical implementation within a project so just as a side note um last year at Rubicon there were two talks that were pretty relevant to pattern lab they're both super great and totally still relevant if you're interested I'd say take a look and they take different approaches that I'm going to go then from what I'm going to go through so form one detox phase two did a talk and then Alexi Peebles also has a pattern lab theme for Drupal all of these take different approaches so definitely go through some of these other resources if this is 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 pattern lab and Drupal 8 work together so the first issue is project structure and it's pretty simple right it's like where should pattern lab live and how should it work but this is kind of one of the high level questions here for me it made sense for pattern lab to live in the theme roof 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 place right Drupal is using one version of twig it's being defined in its composer dot JSON file pulling in all of its dependencies pattern lab 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 pattern lab in any way for instance maybe pattern lab has to restrict the version of twig it uses to some older instance for example then that would also have 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 right we want to be able to update as easily as possible we don't want to depend on some custom patch or some custom hacks 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 Drupal 8 swig and we have our pattern lab twig right our drupal 8 version of twig finds templates anywhere in the Drupal team right it doesn't find templates anywhere else so if you have custom outlets custom modules defining templates you need to hook them into the themes system right you need to tell Drupal about it but any template in your theme root Drupal know about the pattern lab version of twig only recognizes templates within a certain structure within pattern lab the Drupal version of twig it recognizes twig files but it only recognizes Drupal's HTML twig files whereas the pattern lab version of twig will recognize any twigs any file with a dot twig extension which includes HTML twig and then finally based on my previous sort of assumption our pattern lab project is going to be inside our theme so this kind of sets up our problem that we need to solve this is our art 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 bower maybe use node you have some of your theme files down at the bottom the libraries themed info file your asset folders and then pattern lab just sits right there it feels like a theme asset so it feels like that's where it should live so given that pattern lab is inside of our theme roof we need to solve these problems so pattern lab 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 pattern lab 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 coworker wouldn't expect there's somewhere some other person in the Drupal community wouldn't expect right so I kind of want that templates directory to say where it is so the solution that I use for this problem was to just use symlinks so essentially all of your directories in Drupal that have folders that have templates that you need to reference in pattern lab are just going to be sibling Tovar so for instance um we've got our pattern lab source directory on the left and our theme root on the right and you can see 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 filled 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 anywhere else in your theme and you might be thinking looking at this well Drupal has this like hierarchical inheritance based templating system right what about all the templates from class II that I'm inheriting because my theme is a sub-theme of class II 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 class II node template you're going to have to drop it into your node folder right otherwise pattern isn't 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 um 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 exists in your drupal template or in your drupal project and in your pattern lab project and see how all that's tied together so here's our news are like node news teaser template and this lives just where you would expect it to be in your Drupal project without respective 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 - - news - - teaser HTML twig that's all standard twig stuff right and this template is slimmed down for ease of reading sake but essentially the the classi node template by default right we were setting some of our default classes in the classes variable up top we're adding that to the attributes variable on the article and then we're printing out some content so this is pretty standard standard Drupal HTML tag 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 - teaser - 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 - teaser JSON that supplies us all of 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 between 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 note that bundle is is pretty typically used ad 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 as strings write that 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 name right content dot the item in the content area so for instance in our template here we're explicitly printing out content field date and content outfield link even though we don't need to write if in a normal duple 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 of the other because the without filter that you would normally use to hide fields it's 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 rupal is doing with that filter so essentially you just have to choose one or the other in terms of a pattern so this is 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 you have to define in pattern lab as well so if you're using the Drupal default pattern lab implementation most of the functions and filters that are accustomed 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 but the I just wanted to point it out because if you get into this and you don't have 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 labs a static site generator so you change one or two things and you have all the 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 published directory add some sort of golf or grunt tasks it 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 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 on look at pattern lab a little bit before we jump to some conclusion pieces and hopefully have some questions and stuff to talk about so we built a Jubilate site for youth on record which is a denver local nonprofit that works with local youth and 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 homepage just as an example we've got things that you typically expect this to you write a header we've got menus you 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 guide right we have all of our style guide likes definitions colors fonts icons headers some specific header combinations and then we're starting to define things like WYSIWYG fields or WYSIWYG 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 scholar at the top these are all of our paragraphs components right which are just arbitrary groupings of fields but using those defined atoms that we created in 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 paragraphs 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 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 a pattern lab and we're using the same assets right and so if we jump back to our youth and 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 stylesheet 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 an 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 workflows 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 way to think about theming and 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 yeah this is how I want the theme in Drupal right this is all separate from the backend 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 be coupled in this sense means your front-end workflows 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 all you need to do is change one string in your template oh this needs to be some 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 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 to do things like let's only target content types and View mode classes to keep styles component types right or paragraph wrapper bundles or whatnot but if you're using the pattern lab project to actually do your theme 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 this CSS or this JavaScript coming from is it 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 fields 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 dev cons also like the demo content right so that can be pretty useful and communities pattern lab 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 does it 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 patent lab 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 some for some people there these could be a lot of new tools you have to use composer maybe your everyone's already using composer and Drupal 8 or at least starting to get familiar with it but you have to manage pad on live with composer some PHP in the command line you're probably going to be using node and golf to do some helper tasks running if you're not already using that in your front-end team workflow you have to understand pattern lab how the data transform plug-in works how JSON works you have to understand Drupal pretty well how Drupal uses twig how Drupal is how you're going to expect to see templates rendered from Drupal then you have all of your like standard bits right your HTML Javascript your CSS and the big issue could be debugging any combination of these right that provides 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 the team members look like like how how strong are difficult of a workflow can be distributed across all of the members of your team right these are these can be some pretty difficult issues to get past potentially depending on 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 is the end end project workflow look like for your your company your team because the biggest thing like Ted and lab provides some useful things for the 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 like a static point of reference and documentation for the entire project you're losing out on a lot of the benefits that it can provide so what is your project workflow look like can you work this into that or can you make changes to that that'll let you that allow you to leverage pattern 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 these steps and you should be pretty much running um some housekeeping contribution Sprint's tomorrow don't forget open that tomorrow Friday thanks for coming any questions [Music] hi thank you very much for anchor position do you have anything to say about the components module about paragraph component components I don't know the components module it's a module in Drupal org that tries to make it easier to work with things like pattern lab cool I'll check it out just a question about process are you 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 the classy setup 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 um for for that you can you can add any custom CSS to like the pattern lab header so there's like for example with video embed module they have like a tiny CSS file for responsive video stuff right so there's a few manual steps like that and for that case I just added a like a CSS link in the header to the pattern web file to include any other asset dependencies for modules like that external things so there's some housekeeping to tie together because the only direct asset that you're sharing is that mean like theme file theme 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 okay thanks for the presentation where can we find the resources and presentation and sample project I mentioned at the end um if you can go to the session page on the tuple Khan website and there will be a link to the slide deck and the whole slide deck is public all right thank you yeah hi a question about the overall demo that year you had pure all your slides here this is for a single site implementation is that right mm-hmm how have you tackled one single source of truth of pattern lab but across multiple sites multiple properties they still want to have be consuming the design system mm-hmm I think that I think that would depend a lot on what your requirements for your Drupal structure is going to be like is it is it multi-site is it totally separate projects are you sharing things across those projects like CSS assets that kind of stuff like maybe you can you can potentially create a pattern lab project that is all of your shared assets shared structures that that are distributed across multiple projects does what does that scale I think so this implementation by default wouldn't necessarily scale for a multi project set up 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's this feature called leave its pattern States do you know if the data transform plug-in affects the use of that feature I'm not doomed do you mean like the states like approved right um I haven't I didn't implement that feature on this project specifically but so I I don't know the answer but I would guess that it doesn't but that's only I guess I tried it on my side and without includes I think pattern lab acts kind of funny with with some of those things so yeah I was curious if you knew about it but yeah yeah and that's true it is using like a different structure right it's using the kind of supplant the way Drupal thinks about content so there could be some default kind of inheritance things in pattern labs that do break so it wouldn't be surprising that's a good thing to check into the hi there thanks for the presentation I was wondering how designers sort of fit into this like do they still do you in your in your instance they still do Photoshop templates or like how do you how do you talk to your designers in terms of like designing in this yeah um so in this project specifically our workflow is pretty much the same and I was just using pattern lab to implement I think if this workflow were 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 side being there's a lot of things that this can provide for a workflow but that's also a lot of solutions to come one for right or a lot of changes may be in some existing existing workflows and patterns within your company or within your team and that's 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 like the Drupal templates or when you when you build those I've always sort of started with pattern lab and done whatever I want to do in paddle admin that kind of you know work towards the Drupal implementation it seems like you had a lot of very like opinionated kind of Drupal templates what how do you how do you when do you build those and how do you do it such that you're not like forcing yeah such that the pattern building can still be kind of full uh-huh um so my my context in in how I work with Drupal is that I I'm definitely a friend developer but I do a handful of custom code and I'm pretty I'm pretty familiar with like what Drupal templates are going to look like or what some of that like higher-level structures that was very useful in terms of like building things out without necessarily having that in place yet so that kind of background was really helpful but starting with the small pieces like starting with filled implementations getting everything built out for forms for instance because like 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 you've already created the themes related to like these smaller components and you're building out the bigger template and you're just including those other those other pieces so a lot of the work went into the the smaller items the initial like atoms and molecules if that answers your question a little bit so from it from the very beginning sort of 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 ah right yeah so I would usually be taking the data X the like the content acid content architecture point of view from Drupal so like before I before I would start with this even if I don't wouldn't do sight building I would have a pretty built out data architecture plan for like nodes entities field that kind of stuff I think even if that can that changes in the future having a pretty well built out plan for what you're thinking of it in initially is probably pretty necessary for exactly those reasons cool thanks cool thanks for the questions thanks for coming [Applause]

Channel: Drupal Association

Views: 3,795

Rating: 5 out of 5

Keywords: drupalcon, drupal, 2017, Baltimore

Id: W6FuAgr_Kxw

Length: 60min 6sec (3606 seconds)

Published: Wed Apr 26 2017