 All right, we're at a 325. So let's go ahead and spit me. Okay, so yeah, thanks everybody. I'm Brian Perry. This is after five years, my dream Drupal component workflow is finally here. And it's a short session. So we'll just kind of dive right into it here. But I do want to just briefly, I won't give my standard kind of setup here, but I did just want to thank the company I work for, Bounteous. They've been very supportive of me attending events like this and speaking and participating and spending time on the community. So check us out. So I'm gonna start with kind of a little history lesson at least from my perspective here. So from Drupal 8's life cycle, the new are kind of common things for building with components in Drupal. That's an interesting one. So Drupal 8 was based on 10th, 2015, which makes me feel old, I guess. But obviously big change in how the templating, theming, going from PHP template to twig. And then, you know, certainly probably before that time, but even through the release, there was a lot of people understanding what can be done with twig and the power of twig and doing things like including or extending templates. And then later on using embed. Looks like I copied a line twice there on the slide. Shame on me. And then another meaningful milestone at least for me is DrupalCon New Orleans. It was at least the first I had heard of that it was May, 2016. It was at least the first I heard of the components module, which is a commonly used tool in this type of workflow, but also a lot of people who are interested in building with components and using pattern libraries and finding ways to improve that process in Drupal had a lot to share during that particular DrupalCon. Then January, 2017 was the release of the UI patterns module. And this was kind of mind-blowing to me in that a lot of the things that we had done up until that point, mapping twig data in templates, for example, or Drupal's data in twig templates could now be done in the Drupal UI. And then November, 2017, November, 2017 was the experimental release of Layout Builder, I believe. So now we have this exciting new page building experience in Drupal that people are rallying around. But the question is, how does this affect our component-based workflow? And then the thing that I'm kind of leading towards with this is the component blocks module, which was released in July. And this in an interesting way, it kind of bridges the gap between UI patterns and Layout Builder, two things that I've used a lot and really kind of solidifies and ties together this workflow from my perspective anyway. It might not be the magic for yours. But so with that timeline in mind, we're just gonna take a look at an example twig component in this case from a few different perspectives. So I used the nes.css library to create this cool kind of retro looking, I'll get out of the way, what it calls a container component. And we have our twig split on the left there. And the specifics of the markup aren't super important here, but we do have just a handful of variables in our, for all these different approaches, triple data component that lives somewhere else, a lot of down to, we're gonna get the data into those variables. So looking again at the container, so platform and year, which are tags and image, some body texts, stuff like that. So now we'll first look at doing this data mapping in code in a twig template, which was kind of, and still is really a common approach to this problem. So we have the container component that lives in our component library, which is somewhere other than Drupal's default template directory in this case. And we can see what it looks like in pattern lab, for example. And now we need to take data from Drupal and pass it through to that component. So in this particular case, we'd need to use the components module and the components module, if you haven't used it before, allow us to create twig namespaces. So it gives us a nice little shortcuts to places where our components live. But also it's necessary to even get Drupal to recognize templates outside of the default templates directory. So again, thinking about mapping this data in a twig template, we have a game content type that has just a handful of fields that in this case map pretty nicely to the variables in the twig template. And we wanna display this container using a view mode, the teaser view mode in this case. So in mapping the data, we're using the concept is often referred to as a presenter template in twig. So essentially like a traffic cop in the middle where Drupal expects the template to live, a default template suggestion in this case, node game teaser.html.twig. But as you'll see here, we're using twigs include to include the container template that lives in our pattern library. We're using that at components namespace. And then we are listing out and mapping the data in Drupal, the data available to Drupal to the fields in that container template. So we see things like label and then content.field platform year and so on. And the end result is we'll get for that view mode, the card or container in this case, displayed like we expected. So then as we talked about, the UI patterns module came along and provided a way to handle this mapping in the UI. And that was especially attractive to me because while the idea of doing that mapping in a twig template, or you can also do similar things in pre-process, it definitely gets the job done, but it always felt more complicated than it needed to be for me, especially to somebody who's at the time new to twig or you really have to know potentially a lot about Drupal's render arrays and where that data lives and you need to be careful and not strip out too many things. So the idea of doing this mapping in the Drupal UI was always very attractive. So the way I describe the UI patterns module is that it's a way to define and manage components in a way that you can use as a reference. And patterns are Drupal plugins and you can do UI like I mentioned and we'll see a quick example of that. And it closes a optional pattern library page in Drupal, kind of like a mini pattern lab type of thing. And so a number of other cool bells and whistles that you can do, you can pre-process, render them radically. You can create libraries with your patterns and things that we just won't have time to get into today. But if you're interested in learning more, I've certainly given a number of talks on UI patterns even specifically and there's also a great documentation for the module. But again, looking at our container, in this case, we're going to, the thing that we're rendering is a pattern, the container pattern. And the things that we're plugging into are really just the same fields from the template that we've seen already. And this is a quick look at a pattern.yaml file. So to create a UI pattern, by default, you need to create one of these patterns.yaml files. And we won't go into everything this can do, but the pattern has an ID of container, a label, a description, and then a lot of the work here is listing out the fields and specifying a label. The type is something that's mainly used for UI patterns documentation. And then description and then some preview content. So in some cases, we have just a string we're passing in there, also markup and there's some other things you can do there too. So by defining that, we then will have access to these patterns in places where, so there are a handful of integration modules that UI pattern ships with. So basically anywhere that you can use a layout essentially, you could use one of these patterns. The one we'll look at just as a quick example is UI patterns views. So for a row in a view, you can specify that you would use a pattern. So here where it has show, we pick pattern and then under the settings, we have for the row style options, we can pick the particular pattern, the container pattern in this case. And then for each piece of data, each field in the view, we can map it to the destination in our pattern. So we can actually just handle that mapping in the UI rather than digging things out of render arrays and code, which is great. Also just worth noting potentially in the area of self-promotion here, but I also maintain a module UI patterns pattern lab, which the end result is gonna be the same thing as what you got out of that previous example. But rather than having to manually define the patterns.yaml file that we saw, it can automatically discover templates from a pattern library. So there's a lot of overlap potentially in the data that you define for your component versus the fields that you have to specify in that patterns.yaml file. So it can eliminate that redundancy. There are certainly some limitations there, expect particular conventions. It might not work with all pattern libraries, but especially if you wanna take, think with this concept in mind, it can be useful. So then just thinking back to that timeline that we saw before, thinking about layout builder. There comes a, the question is how that component based with layout build. Again, thinking the same container components and layouts. So now we can think of a layout in Drupal. What a layout consists of essentially, we were to represent this at a layout, a region essentially for all components. And then, so a few things to kind of keep in mind. So if we were to use layouts to represent these components, first off, you need to make sure that you don't essentially pull out the things that Drupal and layout builder depend on for things like its drag and drop functionality. So you need to make sure that you're using attributes and have certain wrapping divs for each of your regions. Otherwise, things will break and get hairy pretty quickly. And then there's also the fact that using layout builder is going to require you to use essentially a visual representation of your component when you do the mapping. So, for example, we have a layout for this container, but you'll see here that while you certainly can use it with layout builder, when you start to look at like the tags there, some of the ad block sections tend to overlap and it really doesn't lend itself to situations where you might have fields that are not even going to be displayed visually, but do change the display of the component. And you can do that in like code for a custom block, but it's definitely some extra work to do that. So that finally brings us all the way over to component blocks here, which I think really ties a lot of these things together if you do have an interest in being able to control and map data into your components in Drupal's UI and also do tend to use layout builder. It really ties things together. So it's a recent release, they have a stable release, but it hasn't been around for all that long, but it exposes UI patterns to layout builder. And really just kind of streamlines that process in general, there are definitely ways that you could have had UI patterns play with layout builder, but it makes the process a lot easier. And also it sidesteps some of those visual layout issues that we just saw. So it's gonna give you any of the fields available to the entity. So like if we're looking at this game content type, all of the fields on the game content type will be available to put into this. I think my headset decided to just disconnect. Am I back? All right, great. Thanks a lot, fancy headset. All right, so you can use all those fields that are available to the entity or you can also just pass in fixed data. So let's just take a quick look at what that actually looks like in practice. Thanks, chat for having my back when the audio went out. Okay, so we're still thinking about our container component here. So we have a section and we wanna add a block to it. And then with this module enabled, we have the component block section. So all of our UI patterns are gonna be available there. So we just have this container one. So we can add a container block with fields from content, the game node in this case, or a container with fields from the user entity, which this also has access to. And then once we add our block in the sidebar here, we can configure all the mappings just in that sidebar and not visually yet at this point. So essentially the configuration is more like what you might be familiar with like the general like managed display tab at the component level. But then when you get to the layout level, you can still have that visual representation of your page. So we give it a title and then for each field, you just specify what source goes into that field. So title goes into title unsurprisingly. For platform, this is just an example of picking a fixed input. So we could just enter in the text that we want for the platform. And then just another kind of example of what you can do, basically all the configuration options are gonna be here. So for an image, we can pick the formatter, the image style that we're gonna use, if it's gonna be linked or not, which is all really great. So it sidesteps those visual issues, but then you will still get the visual representation of your component to place at the overall like layout and page level. So I think that mix works really well, kind of doing the field by field at the component level and then still having the visual representation for the overall layout. So pretty much up on time here, but I really, as far as what I have been trying to do with all of these pieces of the puzzle, I've tried a lot of things to do specifically this. And this module component blocks has come along and really solved that problem I've been trying to solve, which is great. So being able to handle the mapping in the UI, it's a really great streamlined way to be able to do that, especially if you're using a layout builder. And then as far as making it easier to package and distribute individual components like this module doesn't specifically have an impact on that, but UI patterns in general, is a way that you could, with the YAML file and all the template markup, you could actually just ship and share and reuse components that way. I also am interested, as I mentioned, in kind of evolving and improving the way that Drupal can automatically discover these components. But overall, just looking forward to us as a community, continuing to build amazing components and component-based sites using Drupal and keeping the learning going. So this is still new and I really haven't had the complete chance to fully add this module to my workflow, but I'm really excited about it and looking forward to seeing where it's gonna go. So a couple of things as we wrap up at two, not my time, there's a bunch of amazing talks going on, so much great content. April and Mauricio are people I always love to see speak, along with Sam as well, who might even be in the chat and on the session. And if you're interested in this stuff, that talk I'd certainly recommend, the single file components module is definitely another interesting way to be able to create kind of easily packageable and distributable components and really cool if you're into the view style single file component concept. And there's also a sponsored coffee break coming up. I don't know how exactly it's sponsored in my house, but I am definitely gonna go have a cup of coffee and enjoy the coffee break. And we're pretty much up on time. I do have some questions. Uh-oh. Okay, let's read that Mark will go, but glad he's back. So some question Mark was wondering how I set up the video. Yeah, it's definitely like unnecessary technique that can't help the bells. Called the worst name ever. But it does like this green screen type of fat cool way to be able to integrate your slot with video and really just spice things up. It's pretty early in beta, but it's really fun to mess around with. I'll even try to drop that. Yeah, that's pretty much it. Thanks everybody for saving me when the audio went out. Hope everyone enjoyed it. If there are any other questions in the chat, feel free to drop them in. Otherwise, I'm around and look forward to chatting. Thanks everyone and thanks Bad Camp. Loom.com Dave suggests. Cool. And let me, I'll try to drop a link to that in the chat here. There's also an album by the band Reliant K apparently. Oh yeah, Slack's a good idea too. So Dave, I'd definitely be interested if you want to ping me in the chats or on Slack about the challenges you're running into with this type of workflow. I agree that they definitely are there. I'd love to know more of what you're struggling with. And Mark, so you can specify in this app that you have a green screen, but this is actually without any green screen. You can see if I put my hands in, it kind of goes to heck, but it's able to do this without an actual green screen and would be way better with a real green screen, which may be someday. Very cool Dave. Yeah, I guess really all I can say is, feel free either in the Drupal Slack or on Twitter or whatever, as you go along that process, if you have questions, be happy to talk. So, all right, cool. At this point, I've stolen two minutes extended from this 20 minute session. So I'll drop, but thanks everybody.