 Welcome, everybody. Thanks for checking out this talk. It is an overview of Drupal front-end component integration methods. A couple of housekeeping e-things. There's the bit.ly link there, bit.ly slash component dash int. That's going to take you to a little sandbox repo that has the examples I worked up for this talk, and also links to the slides and also past versions of this talk. Also, I'll try to keep an eye on the chat, but mostly we'll loop back for questions at the end. If you want to just tag your comment in the chat as a question, that'll help me track it down, but otherwise have fun in the chat. Let's get going here. All right. I'm Brian Perry. I'm a lead front-end developer at a company called Bounteous. I live in the Chicago suburbs, and I'm a lover of all things component and component-based, which obviously is very relevant to what we're going to be talking about today. Building and theming with components in Drupal, design systems and tools like Pattern Lab and Storybook, and increasingly building with component-based JavaScript frameworks like React. Also, a lover of all things Nintendo. I'd love to talk about what you guys are playing on your switches. For me, it's Animal Crossing, New Horizons, and I'm very excited for the Paper Mario game coming out this Friday. Yeah, Nintendo FTW. Then I'm available on the Internet in a variety of places and would love to Internet with you. As I mentioned, I work for a company called Bounteous, back when everybody was going into offices. We have a number of offices throughout North America. I mean, we still do. I was based out of one of our Chicago offices. Drupal is one of a handful of things that we do at Bounteous, but I predominantly work in the Drupal practice with a bunch of other great Drupal folks, and I learned so much from everybody on a day-to-day basis. If you're looking to do great Drupal work, we're often hiring, and if you're looking to have great Drupal work done, I can certainly get you in touch with somebody. I did want to take a quick moment to kind of acknowledge the ride we've been on lately and this interesting year, and this is happening remotely, just to say that it's been really meaningful to me to be part of the Drupal community during this time and have ways to contribute back to the project. And it's also great to be part of a community that takes diversity and inclusion seriously and is looking to improve ourselves there and also acknowledging the mistakes that we've made along the way. So looking forward to be able to do this sort of thing in person, again, in the future, but also happy that we have what we have now. So we're gonna talk about components, obviously, and specifically ways to pass data into them and integrate into them, but I just wanted to really quickly up top talk about component-based development just at a high level. I'm not gonna spend too much time selling this concept. I've spent entire talks on that in the past, but so component-based development is the idea of building with modular and reusable elements. So building a system rather than a series of pages. So if a developer hands off a Photoshop mockup of a page, first off, maybe you should have a conversation with them about that, but rather than building just that instance of that page, it's breaking it down into its component parts so that they can be reusable and they can be used to make that template and other templates and that instance of that page. And it often uses a pattern library tool for documentation and so things like pattern lab and storybook, but those tools aren't required to take this approach. You can still break things down into their component parts without using a tool like that. And this approach can also help decouple backend and front-end development in some interesting ways. So you can build these components in isolation before the functionality exists in Drupal. Theming doesn't have to be tacked on at the end, good things like that. And it's popularized by Brad Frost's atomic design concept, which is really just one way to describe and talk about breaking things down into their pieces and combining them into larger elements, but any way that it works for you to talk about and think about that concept is valid. So today we're basically just gonna look at one example component in twig specifically, a number of different times and look at all of the different ways that we can use it and pass data from Drupal into it. And I wasn't joking about my affinity for Nintendo. So I took this opportunity, we're gonna be looking at this container component on the right-hand side there. And it uses the NES.css framework, which is a little CSS library that allows you to create cool old school Nintendo pixelated looking styles. So the component itself has really just a handful of variables in it. There's the title and a couple of tags, the platform and the year and image, body text and a link. And then a quick look at the twig template for this component. So we're using the classes from the NES.css, NES container with title, et cetera. We have some conditionals for the different variables. So we're not going to render markup if there is no data passed into the field. And then we have like a wrapping div for the badges that we see there. And also obviously the variables themselves, platform, year, image and so on. Oh, thank you Christina for posting the link to the repo. I should have done that. Okay, so this is a YAML file that has data for this component. And so this example that I built is using pattern lab, but other tools have similar concepts. So it's really just representative data that you can use to render an example of the component. So we see we have things like some strings markup and so on. And then one other little piece of the puzzle here is we're going to take our container components and we're going to render them in a grid, a three-up grid here. Nothing all that complicated going on in the CSS for this. It's just a grid class that uses CSS grid at different responsive breakpoints. So now let's talk about, now that we've seen this example component and what it looks like outside of the context of Drupal, let's talk about components in Drupal. And there's a few different kind of dividing lines I'm going to use along the way here. The first one is where your components live. And from the perspective of this talk, I'm going to divide it into what I'm calling a standard Drupal component and an integrated Drupal component. And really the difference from my perspective is a standard Drupal component lives in Drupal's default templates directory, either in a theme or a module. And because of this, it's not going to require much or potentially even any effort to get data to display in it. It's kind of where Drupal expects to find it. And then an integrated Drupal component lives anywhere other than that default templates directory. And as a result of that, it might require as likely going to require some additional effort to get data to display in it. And for this talk, it doesn't really matter how those integrated components get into your theme. It could be just a subdirectory in your theme. That's what I did here just for the sake of simplicity. It could be a completely external dependency, but the general concept of getting data into it, a lot of those are going to be similar regardless of where it's coming from. So a standard Drupal components first, and we're going to talk about some other kind of more complicated approaches, but doing what Drupal expects could very well be right for you and your team and your project and potentially the scale and complexity of your project. So here you're going to be building with Drupal and probably only Drupal in mind and taking advantage of things that can be easily reused in Drupal. So things like display modes and blocks and people often use paragraphs as a way to represent a component layout in Drupal, another potential thing that can be reused as well. You will lose out on some of the rapid prototyping advantages we talked about by not using a tool like a pattern lab or a storybook or having basically the issue here is that you're going to have to stand something up in Drupal to see what it looks like. So let's look at our components from the perspective of a standard Drupal component. In this case, the thing that we're using is a view mode, the teaser view mode in this case. And we have a game content type. So the game content type has a label that represents the title and then a handful of fields that really kind of map one-to-one to the things that are in this component, year, platform, image, body, so on. So here we have a template suggestion for node game teaser, which is just copied from the default node template in the classic theme, in our custom NES theme. And then in the classes array, we're adding some of the classes that we need from NES.css, so that things render all Nintendo in pixelated. And then the rest of the stuff that you see is from the default node template. And if we look a little bit lower here, we're really just kind of reworking the markup and bending the markup to the needs of our component in this case. So you'll see that we have like a wrapping div for the badges with the NES badge and isSplitted class. And then we're also kind of explicitly rendering out the fields where we need them. And then the grid layout, we're just creating a view for this called games. And this is a unformatted view template. And really we're doing very little here aside from wrapping the markup that this provides by default with our grid class in order to get it into our three-up grid. So that was kind of following Drupal's lead and doing Drupal's default there. Now we're gonna take a look at integrated Drupal components in a handful of different ways that we can deal with components that live outside of Drupal's traditional templates directory. Excuse me. So as I mentioned in this example, I have a pattern library and it lives in my custom theme in the NES components sub directory. And I'm using pattern lab with it. So it kind of follows pattern labs default structure. There's a patterns sub directory with a components directory inside of it. And then in there, a container sub directory. And that has all of the things that we need to render this component, which in this case is just a twig template and the YAML file that has data. And we can see in pattern lab what it would look like with this example data, examples of markup, all that good stuff. So now if we're starting to think about how we can use it in Drupal and get Drupal's data into it, the first thing that we're gonna need is the components module. So this module allows you to create twig namespaces and let's Drupal discover templates that live somewhere else than the templates directory. Cause that's where it would, the only place where it would discover templates by default. So in our info.yaml file here, we have a component library section and we defined a component namespace that points to that components directory that we saw. I'll be saying the word components frequently. And then now that Drupal can find that template, the next kind of forked in the road is how we're going to provide the data to it. So the kind of two categories of integration approaches are mapping data in code versus mapping data in the admin UI. So mapping data in code is gonna include mapping data in twig templates, using preprocess or kind of potentially any, backend code approach that's gonna queue up your data. This approach is more likely for my experience to get out of sync with the Drupal UI. So like not reflect what's in the managed display tab, for example. And then also, if you're not careful and strip out too many things, it can also be more likely to break things that Drupal depends on. Like a quick edit is a common example or cause issues with caching. And then mapping data in the admin UI on the other hand uses the, can use the UI patterns module. Drupal layouts would be another way to do this. And because it's a Drupal module and kind of going through Drupal, it's less likely to disrupt Drupal functionality but potentially not as flexible in that, these modules have a particular feature set and follow certain conventions. So integrating in code, all of the things here are the same. We're still using the teaser view mode and our game, Neuron has all the same fields. So the first approach that we're gonna look at is mapping data in a twig template. And these examples are kind of intentionally quite simple. But here we're using what's often called a presenter template, a twig presenter template. So for that same template suggestion, no game teaser that we saw before, we're including the container component from our component library and using our little namespace shortcut of components there. And then we're saying with and listing out all of the fields that are in our component templates and specifying what data that this template has access to should go into that. So label for the title, URL, platform, year, et cetera. And then alternatively, this could be done in pre-process as well. So this is a in our NES.theme file in our custom theme, pre-processed node hook for the game content type. This is probably the world's simplest pre-process function. All it's doing here is just taking the variables that are already available to this node and mapping them to where they need to belong in the variables array. So the component template can find them. There's obviously a whole lot more than you could do here. There could be a bunch of logic in your pre-process. You could reference other things. But this is just a really simple example of just taking the data and putting it where it needs to be. And then back in the twig templates in Drupal's template directory, the presenter templates, all we have to do is include the container twig template from our component library. We don't necessarily have to map out all of the individual fields because they're gonna be available to that component template. And especially from the perspective of mapping in a twig template, there's some helper modules that are gonna prove very useful. Twig field value is one of them. We'll let you get partial data from field render arrays. So that field value function is going to allow you to get just the content and not default wrapping divs so you can map just the data that you're looking for. You may also, though, need to be careful and take additional caching considerations, especially if you're using something like that field target entity. So that Drupal knows when that entity is being referenced and needs to be invalidated. And then twig tweak just provides a bunch of helpful functions and filters. You can render views, blocks, regions, images with specific image styles. So if there's something that you're trying to do in a twig template that's proving difficult, definitely check twig tweak. There's also a handful of other similar modules that may have already solved that problem for you. And then also kind of in the same neighborhood, there are a bunch of starter kits and themes in the community. And this is really gonna give you a great starting point for setup and provide default tooling for you if you don't want to build your front-end workflow from scratch. Some of them have components that they ship with and they're gonna have varying levels of how opinionated they are about their work plan, things like that. But the emulsify theme is quite popular for people that are new to this component-based theming approach. Gesso, the Shiloh theme and Particle are all other great options. And again, can give you a great starting point to take this approach. And because at the end of the day, they use a similar approach to component mapping, there's really not a whole lot to show here, but the one example that I did take a quick look at was using emulsify in their most recent release, which is emulsify design system. And one thing that's interesting about emulsify design system is it uses storybook for HTML as opposed to pattern lab, which it's used in the past. So here we're still using the same presenter templates and the same component templates, but they just live in a different location per emulsify and storybooks conventions. And it's a different component library tool, storybook in this case, but we still see our components, all old school Nintendo looking with example data in it. How we actually define our story in this case, rather than pattern, is a little bit different. There's a JavaScript file, but still conceptually we're doing the same things. We're specifying where the template is, importing any assets that we need, providing data from the YAML file to our component and rendering out our example. And then here's an example just in a sub theme of emulsify where at the end of the day, we just see our same container component. The mapping process is still really similar here. So now let's look at some ways that we can map data in the admin UI. I see definitely some good chatter in the chat, which is awesome. So the first example we'll look at is the UI patterns module. And the way that I like to describe UI patterns is it lets you define and manage components in a kind of Drupal-centric way, a way that Drupal better understands. So UI patterns are Drupal plugins. And when you've defined a pattern, you can configure the mapping in the admin UI. And there's also an optional pattern library page that's just exposed in Drupal. It's kind of like a mini pattern lab. And you can also do things like pre-process your patterns, render them programmatically and all kinds of good stuff like that. So in this case, the thing that we're using and reusing is a pattern, the container pattern in this case. And the variables are all the same variables that we have in our twig template. So to create a pattern, we need to create a pattern.yaml file in a pattern subdirectory in our theme in this case. And you can have multiple patterns in a single yaml file, but the convention I typically see is a single pattern per file. Then you have an ID for your pattern, a machine name, and then label and description. And then a lot of what you see here is defining the fields. So each field has a type, which is mainly used for documentation, label, description, and then preview content. So some of these are just strings. We also have markup. And there's a few other things that you can pass in there. And that's used in the example pattern page. And a little bit lower in the yaml file, there's some other cool tricks here. You can define libraries. So if there are certain assets that your pattern depends on, when you use this pattern, it'll be loaded. And you can also use the libraries defined here as dependencies of other libraries and other components. And then the use statement is really great in that it basically tells this pattern, when you're loading this pattern, use the template here in our component library. You can even use twid namespaces there. And it essentially prevents you from having to actually create manually that presenter template in the middle. It's doing something similar behind the scenes, but you don't actually have to add it to your code base and make it here. And then this is an example of the pattern library page, which obviously looks a little bit crazy due to all the NES.css. But there's our container component, that we've seen a handful of times, a table with all the fields. And this kind of serves as a great kind of piece of Drupal documentation of the things that are kind of Drupal admin ready components that are Drupal admin ready for you to provide data to. And then there's a handful of integration modules, but we're just gonna look at one for the sake of example, UI patterns views in this case. So within enabled in your view, you can specify that you wanna show a pattern. And in the row style options, you can specify what pattern you wanna use and then you're able to map the fields in your view to the variables in your pattern. So title those title, body, body and so on. And then as a result for every row in your view, it'll be rendered using that pattern and our container template. I see some semantic debates in the chat, fantastic. So another way that you could represent this is using a Drupal layout. So in this case, the thing that we're reusing is a layout, a container layout. And then layouts have regions. So the region, the data for the region is what we're passing to our component template. And there's a handful of ways that you can find layouts. In this example, we're using a layouts.yaml file and our custom theme. And so there's a machine name for the layout, label, category. The template obviously is pretty important and that needs to live in your templates directory and have a HTML.twig extension. And then beyond that, you're defining the regions for your layout, which in this case, map to the fields that we've talked about over and over. And then in our layout template, we're including our component template, as you might expect. And we're mapping the regions, content title, content platform, et cetera, to the slots in our component. If you wanna use these layouts with a layout builder, there are definitely some additional considerations you need to think about. So really what it comes down to is that you don't want to strip out the things that the layout builder UI depends on. So you'll need to use the attributes object, have the wrapping markup that's expected here. So for example, there needs to be a wrapping div with the region attributes and the related class for each of your regions. And this is so the drag and drop UI can pick up on it. So the other thing that you have to think of kind of on the other side is if you're using a tool like pattern lab or storybook, it needs to be able to understand these Drupal specific things like the attributes object and add class. There are definitely, it's definitely a solved problem, but may not be something that is shipped out of the box with your pattern library. So then at the end of the day, when we add a section in layout builder, we can pick our container layout. I didn't give it a fancy image, maybe should have, but we see visually all of the different regions and we can add blocks to them. You'll note here that the kind of badges get a little crowded. So depending on your component, it may not really make sense to represent them visually. It could be especially problematic if there are things that don't need to be rendered visually that you need to represent and pass data to. That might be a situation where like block configuration is the better approach. But so it'll vary a little bit depending on your component whether or not this visual approach makes sense. But it's cool that it's definitely another way that you could represent your component. And so now another kind of split that we can talk about is different component definition approaches. So pretty much everything that we've talked about falls under the category of manual definition. So we're defining our components in code to some degree so that Drupal then knows about it. And pretty much all of the examples that we saw are gonna have some amount of duplication between Drupal and what you're representing in your component library. Like the YAML files that we saw for the data for your pattern versus like things like the layout or UI pattern. A lot of overlap there. Versus the kind of emerging or experimental concept of automatic discovery. In this approach, a Drupal module will discover components in your component library and automatically make them available to Drupal. And this is also gonna require a kind of a particular convention. And as a result, won't work with all component libraries. They'll certainly work with some. And also you might be able to kind of orient your approach around something that is friendly with this automatic discovery. So we'll look at a few examples of that. The first is the UI patterns pattern lab module which is a module that I maintain. And this will discover patterns in a pattern lab instance and expose them in Drupal as UI patterns. So the end result is gonna be the same as what we saw in our UI patterns example. But you don't actually have to manually and explicitly create that patterns.yaml file. There's actually some limitations here. You do need a YAML or JSON file that has example pattern data. That's how it's going to know what fields are part of your pattern. And there's kind of, it can be a little bit challenging and it requires a specific approach if you have like deeply nested components. And then also, since we talked about layouts as an alternative here, there's also the layouts from pattern lab module that I've created that's very similar concept. This is very early, maybe even in the category of failed experiment. But it's the same sort of idea deriving from a pattern lab instance layouts that are available in Drupal that you can use with Layout Builder and other places that you can expose layouts. Similar to what UI patterns offers, you can specify whether or not you want to render the default field wrappers or just content. But as I mentioned, there are a handful of limitations here. Some bugs with the Layout Builder drag and drop. But an interesting experiment in them itself, if anyone wants to try it out or maybe even keep pushing it forward. And then there's also the pattern kit module that falls into this category, which thankfully is not a module that I maintain. It's maintained by the folks at Red Hatch. And this from my perspective kind of has aspects of manual definition and automatic discovery. So you have to create a, or it depends on a schema definition file and JSON schema file, which in and of itself has potentially some applications outside of Drupal. And it can automatically derive blocks from your pattern library components, supports a specific set of field types, it's in active development for Drupal 8, but there's also a Drupal 7 version. And here's a quick example of configuring and having pattern kit discover your patterns. So in your libraries.yaml file, you can add a pattern section with a path to the location of your patterns. And here we're specifying that they're twig. And then this is an example JSON file, JSON schema file, kind of similar in concept to a lot of the different ways that we saw of representing these components and patterns. But a lot of what you see here is representing the fields and you can specify the field type along potentially with some options like the body allows you to specify if it's a WYSIWYG field. And you can also have settings that are specific to the pattern as well. If you want to change layout or styles for the overall component. So what you get at the end of the day is a block type that you can use in the blocks UI. And we have all the fields that we defined along with our settings. And it again is gonna give us something that looks like our container component unsurprisingly. So kind of one last area that I wanna talk about a little bit is prepackaged component solutions. These aren't really going to in many cases address kind of the integration challenge that we've been talking about. But I think are just an interesting option in general. So one that's a real nice fully fleshed out design system is the bulk design system. The folks at Pegasystems built this. And these are a set of ready to use web components of complete design system web components. I believe they can also render as twig. And another cool thing about this is you can selectively require the components that you want to use in your built. And then there's also the Componi project with a great five star name there which describes itself as a component distribution system. And it has a theme, a gulp workflow and components that you can choose from and you can also create your own. At least last I looked at this. It didn't really have a composer or NPM driven workflow, which means that it really doesn't fit into my workflow. But just in general, it's interesting to look at another approach to having Drupal friendly components that can be easily distributed and shared. And then a couple of other things that again, don't directly address the integration problem necessarily, but there's the single file components module. And this allows you to create a Drupal component with a kind of view single file type syntax. So we'll see here that there's twig markup CSS there can be JavaScript logic in here all in one single file. You can then use like any template and you can automatically generate libraries, direct blocks and layouts from them using annotations. It also does have a little component library page that you can turn on. And just I think is very interesting from like the perspective of distribution and reuse of components. And then one last one that was brought to my attention quite recently is the component, not components with an S but component module which was recently released. And it's yet another way that a component can be defined in a YAML file and a block configuration can be derived from it. It seems to be more focused on the decoupled use case. I've only had a limited amount of time to play around with it. And it's inspired by the progressively a couple of blocks module. If you've had an example to use that but definitely something worth checking out but also just it is interesting especially with the handful of these that there are a lot of modules, a lot of approaches a lot of people solving a pretty similar problem as far as, you know, repeatable and distributable components within Drupal which leads really nicely into some of the things that came up in the Drees Note today. I was sneaking and took a screenshot. And so there was a lot of talk about components in general component-based theming but especially the concept of building a, you know small slice admin UI component, a menu component that can be distributed and available in both react and view. And this is pretty exciting given all of the things that we talked about. It'll be really interesting to see where this goes but also I'm hoping that there are things that we can all learn and standards that we can pick up as far as like a clear pattern that can be repeated for making Drupal friendly things that can be easily distributed. So kind of spring from that last thing that I wanna talk about is just kind of overall workflow what I currently do and kind of where things may potentially be going in the future. So the honest answer for me is that I find that I'm still leveraging kind of a mix of some of these approaches. I do tend to use integrated components that live outside of the traditional templates directory. Sometimes that is a external dependency. Sometimes it's not kind of depends on the project but most of the assets live outside of the templates directory. I'm still pushing to try to make the mapping something that can be done in the Drupal UI but find that it's most successful for pretty lightweight components. And then for things that are a little bit more complicated I find that I have been leaning in the direction of using pre-process for things with heavy logic over mapping into a templates. And part of the reason for that is that our backend developers have gotten really good at providing helper functions to make it easier to get data into our components. I've also created some helper component pre-process classes that I've used that I'm hoping to also contribute in the future. And also in general just trying to build components that are friendly to layout builder. So using custom block types and pretty limited use of paragraphs at this point. And a question that you might be asking and I've been asked for previous iterations of this talk is, so what should I do? A lot of great examples, but what should I do? And my general answer to that is I would start with the approach of mapping and code. That's definitely the kind of most battle tested approach. Folks have been doing it for a while. I've had success with it on projects. And which of the mapping and code approach makes sense for you is gonna kind of depend on your team makeup from my perspective. So if it's predominantly something that's handled by front-end developers, they might be comfortable and get more success doing that in mapping in the Twig template. If you're people responsible for this are more backend savvy, they might be more comfortable doing it in pre-process. End result is kind of the same. We're just getting the data where it needs to go. So again, it kind of depends on your team. And then as you become comfortable with this approach and find success with it, then you might want to consider some of the more advanced things that we talked about. And then as far as like kind of what my dream workflow for the future is the honest answer is something like when I'm familiar with working on React projects or pick your favorite JavaScript framework here where there's an ecosystem of easily available distributed components that you can easily install, easily important to your code and use them as you see fit and pass data into them. And that's particularly interesting given some of the things that we were talked about in the tree's note and how we're looking to do that with ReactorView components, but how do we get there? I do think that we have a lot of the different pieces that we need and I know we haven't talked too much about the decoupled kind of view of this, but there are a lot of tools there too. But I feel like the point where we need a little extra Drupal magic and certainly some kind of more focus in the standardization. So I do think that anything that can be done to make it easier to package and distribute components is going to be really helpful. And I think the evolution of web components might help here especially if we're looking to create build components that Drupal can use that are available in both ReactorView. And I'd still like to see improvements in the UI as far as how you can handle these mappings in Drupal's UI rather than it being something that's predominantly done in code and keeping it friendly for layout builder I think is important. And I also, it's probably appropriately prioritized on this list, but I still would like to see approaches evolve as far as Drupal being able to automatically recognize and understand components. But kind of one of the big things is that we just need to keep building amazing and wonderful component-based sites in Drupal. And then also, as I've touched on, I think some of the concepts for these admin UI components is gonna be a really interesting initiative and has a lot of overlap with the things that I've talked about and I'm interested in. So I'm looking forward to seeing where that goes, what we can learn from it and hoping to find ways that I can contribute as well. And then last kind of little shout-out hat-tip here to more folks than I can possibly name, but I wanted to thank all the folks in the Drupal component ecosystem who have shared their learnings and their code and helped me along the way. And I'm really happy to be just a small part in this nice little friendly corner of the Drupal world. So thanks everybody and yeah, looking forward to more. And also would love feedback on this talk. There's the Survey Monkey link, which I think is also in the chat. I think there might also be a link on the session node. And then also at a couple of days next week, also virtual, I'll be giving kind of a decoupled focused version of this talk, if you're interested in that angle on this. And I think we have a little bit of time, tiny little bit of time for questions. And also feel free to track me down elsewhere through the conference or on Slack or whatever. Happy to keep talking about this stuff. Okay, so dig some questions here. I'll probably just have to go backwards. Can we get your slides with the first one that I saw pop up? Yes, there's that bit.ly link that is earlier in the chat. I'll also tweet them up, tweet them out, tweet them up apparently is the thing I invented. And the repository has them. So I think it's like bit.ly slash component dash int, also drop it. Drop it in there. What are your thoughts on having a component-based theme and also Drupal modules with design and presentation elements built in? How do you go about connecting design and interactivity from these modules into Storybook or Pattern Lab? Do they need to be recreated from Scratch in Pattern Lab or Storybook? That's a good question. Hard to answer succinctly, but really what I focus and I think others kind of recommend there is that there potentially needs to be distinction between Drupal and the components in your component library in that they shouldn't necessarily have Drupal-specific things in them. And if you do that, it makes it easier for you to integrate them into Drupal and into potentially other CMSs as well. So if you find yourself doing a lot of very Drupal-specific things in your components in a separate component library, you're probably making it harder for you to be able to reuse them potentially. Hopefully that helped. Let's see. What else? Scrolling back, scrolling back. Thanks for all the thanks and positive words. Definitely good chat back here. A lot of requests for my slides. Appreciate that. If anybody has a question that I'm not seeing, they really wanna make sure I catch. Feel free to drop it in again. So comment on security coverage for these modules, which is a very valid point. Let's see. Yep, there's a good question from Kevin earlier about handling cash tags and other metadata. And Mario had a good answer there. They can be achieved by ensuring you're passing the full content array versus only the field values. I think there was some good chat about pattern lab versus story book. Question, is it fair to say emulsify saying goodbye to pattern lab? Yep, that does seem to be the case. Cool, I'm sure I missed some. Oh, here's one from Mario. What is your default method for integrating components? Yeah, my default method for integrating components really at the end of the day probably still is mapping in code and doing a lot of the heavy working pre-process. Yep, yeah, presenter templates, but Mario, I would say that by doing more of it in pre-process, there's a lot less that actually has to happen in the presenter template. The presenter template itself is pretty lightweight. Yep, and then mention about the security coverage, concerning modules that I've been presenting. Again, that is a valid point and something that I probably should go out of my way to mention, there are various levels of coverage or lack of coverage. As is the case with other things in the Drupal ecosystem, you need to consider the risk there and look at the modules and see if they're things that you're comfortable using. And also, it'd be good for us to try to push to get security coverage on some of these modules. All right, I think I am up on time. I appreciate all the great chat and questions and feel free to follow up if you have any questions. There was one last question, is necessary to create a for every view mode per content type, a template to integrate with the component? No, it is not. There's lots of ways that you could reuse that. For example, if you're including a component template, you could include the same one in different view modes. Cool, all right, I'm gonna wrap up because I'm over time, but thanks everybody. This is great and TrooperCon Global has been awesome so far and look forward to participating more in the next couple of days. Bye.