 Oh, we have one person that used Storybook with Drupal, maybe four or five that used Storybook. So I was just asking, because when we get to the Storybook demo part, I will definitely do that part. OK, so we're going to talk about how to basically make it work for Drupal, or tips and tricks for how you can build your own, basically. My name is Melissa Miller. I worked for Pantheon, a senior UX engineer, working on rebuilding a design system at Pantheon. I just started there earlier this year. Prior to that, I worked in higher ed for many, many years and started the first design system at Ohio State University. Still in beta, but it's almost done. I check on it periodically to see how it's going. And then I've been using Drupal since 2011. I'm from Michigan, Ohio, California, place where I lived, musician, I love dogs, it's my dog. And so what is Storybook? It builds itself as a UI builder. Some people consider it a design system holder, component library, living style guide, et cetera. As we talk through this, I'll probably be going to use the word toolkit a lot, because that's how we refer to it in our work at Pantheon, because we're building the complete design system, and then we have toolkits for different contexts. So we'll have a toolkit for React for the product, and then we'll have a toolkit for TWAG for the website, et cetera. So if I use the word toolkit, it's basically what I think of as our implementation of Storybook. But people use it in many different ways. But just to get a little nerdy here, the design system is actually the set of standards and practices and documentation. And then there's tools to implement it. But so this is what Storybook looks like. We're actually going to walk through it. But it offers controls that you could basically see changes in real time. And these are basically arguments. If you're used to React, you can put props that you can pass in for Drupal think-like variables. But anyway, we'll walk through that a little bit later at the end, just show you one in progress. So if you notice, this is a screenshot from Storybook's Docs website. If you notice, there's no Drupal or TWAG version in this list. So the ones up here, these are officially produced by Storybook. And these are the community ones. But they're pretty good community ones, so they get top billing here. So how are we going to do this? We're basically going to take the HTML version and air quotes hack it to work with TWAG. And it's not terribly difficult once you figure out how you want to do it. But first, before you decide if you want to have a design system or a Storybook or a toolkit, is it a good idea for you and your project? So I have kind of like a pros and cons list. So pros or why you might want to do it is multiple sites or themes will be using the toolkit either now or in the future. So if you want to set up a bunch of base components that you're going to reuse or you have a brand that needs to be spread across different sites, this would be a great use case for it. Different people or teams will be building the toolkit than those who are building the site. And that's actually my use case. So like I said, I work on the design systems squad and engineering at Pantheon. A different team actually builds the website. They have a web development team in marketing. And so we work together. I've been building the toolkit. And they've been consuming it in the Drupal theme. So that's my particular use case, why this made sense. And then sometimes you want to build out your UX ahead of implementing it in the site. You need to show a client. You need to get approvals. You just don't. You're not ready to build the site. This is a great way to do it storybook. So there's a few cases where you might not want to do it. And again, either both of these lists are not exhaustive. These are just what I've encountered. There's a one-to-one toolkit to site relationship. You're building one Drupal site. And that's it. You might not want all this overhead also building a storybook or any sort of other design system. But maybe you do, but it's not very efficient. And then the other one, this is more storybook specific, but the rest of the points kind of relate to design systems in general. This last point is storybook specific. If you're not tied to storybook, you might want to choose a different tool that already has twig built in it. The only one I know that I can actually vouch for is Fractal. I've used it in my previous work. Fractal's more of a plug-and-play where you basically, there's a single core. It's not like how storybook had all the additions. This is a single core Fractal, and then you plug in what you want to use. So they do have a twig-flavored template engine that you can plug in. I prefer storybook. I think it's a better tool, but Fractal's also very nice. You might want to look into that if you're not specifically tied to storybook. Personally, we're using, at Pantheon, we're using storybook for everything, so it just made sense to kind of hack it into the twig version as well, so we can use it everywhere. Just so for, I guess, for the designers or whoever's approving and looking at it, it's a uniform experience. They can look at each of the storybooks. So, if yes, if you decided that this is what you want to do and you want to use a design system, do you use an existing tool or do you use a do-it-yourself? So, I have, in my research out there, I've found and played with a little bit each of these tools. A Malsify design system you may be familiar with. It's been around for a while in a lot of different iterations. They used to have pattern lab baked in and now they're using Gatsby and storybook. It's great. It was way too much overhead for what we wanted to do. It was a little too much for what we needed, but it's a great system. You might want to try it out. The other one is Wing Suit. I don't know as much about it. I think it's Strip for Developers in Europe that are building this one. It looks pretty cool, but, and again, both of these cases, I didn't want to take something big and strip it down. I wanted to start from scratch and build it up. So that's why I didn't choose one of these, but I just want to kind of give a plug to these. So I already kind of started this, but why DIY? So I wanted to keep it lean and build from the ground up rather than stripping down an existing product or project. You want to organize the toolkit as you see fit. A lot of those are opinionated. I think the two I mentioned are kind of getting away from that opinionated and they're doing their optional plugins that you can add to set up your base structure. But back when I started working on this, almost a year ago, they had very opinionated ways to organize, like the atomic structure or other ways. And you may just kind of want to have your own organizational structure. And if time permitting, I'll talk a little bit about how I've decided to do it for our work. And then, or you just want to understand how it works and be able to extend and customize the platform either now or in the future. So these are use cases why you might want to build your own. Okay, so the top one was mainly mine. But how? So these are the four main high-level things you need to do. How you actually do these, it's flexible, it's up to you. I'll share the repository. And when I share these slides, the first two are linked, how I'm actually doing them in the toolkit. I'll touch on it briefly, but this is kind of meant to be a high-level overview. And if we have time, I can definitely show the code, but basically you need to achieve these four things. And I have my opinions how to do them based on what makes sense for me, but do these in your own way, basically. But the first one is you basically, you got to get Storybook to recognize and load twig files. You could do that with a twig loader in the web app, and that will be in the repo. And then you probably also want to emulate Drupal-specific twigs, stuff that's not in the native twig spec, but we use a Drupal or we've added on a Drupal. So there's a couple of really good packages out there. Obviously, in the package JSON of the project I'll share, I'll show you, it'll show the one I used, but I think there's at least three that are all like variations of that initial package. But yeah, you basically emulate that in Storybook, so it's available for you to use. And so when you ship your templates to your Drupal site or theme, you don't have to alter the functions or any of the extra special filters or anything. The other thing, the next thing, is to create a wrapper or a process to use Drupal behaviors, because you probably want to use Drupal behaviors on your site for your JavaScript and your jQuery. But Storybook doesn't recognize that. So we basically, we sub in a function or a JavaScript class that kind of just wraps. Basically, it lets Storybook recognize Drupal behaviors and display them in Storybook, because Storybook is just our display. We want the real stuff to go to Drupal, so we want to write our JavaScript in the way that Drupal wants, so that Drupal will use it and it's best for Drupal. And then so we're just kind of emulating things to get Storybook to display it properly. So this is number two. I basically ripped straight out of a multiply, I referenced it in the code and pointed back to where I got it from and it's gonna have to be adjusted a little bit. One of the functions that we use is deprecated and it will be gone in Storybook seven. So we can use it for now, but basically I stole a mouse flight method for that and it looks great. And then you want to package up your assets. In this particular case, in the demo project, I'm shipping compiled CSS, minified and regular, compiled JavaScript, minified and regular, and then I'm shipping a twig file for each component, not foundations, not recipes, stuff like that, but each capital C component gets its own twig file that goes with the package. At Pantheon, because of the work we've done with the web dev team, they wanted a few more pieces, so I've also shipping some CSS partials, I'm also shipping individual JavaScript in case they want to pull it in on a library basis instead of overall. But this is kind of the base level of what you want to do. And then you just distribute it. So I've chosen to use Composer. You can certainly use NPM. Depending on what you're shipping, you can even do a CDN. If you're just shipping the JavaScript or the CSS. So yeah, I like Composer. I'm using Composer installers to plop it right into the folder I want in the theme. But again, all these are kind of, you know, up to you, as long as you do them. Oh, and my little asterisk here is basically, this number two is specific to Drupal, but the other stuff is very general. And so this could be more of just a twig storybook than a Drupal storybook. So if you have, you know, it could be modified to use with WordPress or like GraphCMS or something, other systems that use Twitter. Yeah, there's the node there. Any questions so far? Yes, Eric. Because does the, I'm not familiar with storybook at all. So like you're creating these patterns in a storybook. Can you recompile the patterns for like all the different projects? Like I want a spelt version. I want a trade version. I want a version for Vue.js. Does it do that for you? Or is that more of a manual process? You, it's more manual. It's more manual. Yeah, unfortunately there's like the different flavors of storybook. I mean, you might be able to act something together, but I don't know that it's good for that. So it doesn't, yeah, okay. Yeah, yeah. All right, moving on. Okay, so I have this project. I'm gonna try to share out the slides after this. We're using a different system this year for back camp for sessions, but I think we can attach stuff to it. But if not, we'll figure out how to get these to you. But where is my, how weird. My whole screen was like back one. You guys are not seeing, I'm seeing. Okay, that's weird. Okay. Anyway, so this is the link to the repository. And it's a demo project that I set up basically just for this purpose. I didn't want to show the Pantheon one because we've done a lot of additional things that might not be relevant for base level. But I'm actually gonna keep working on this. I have some, well, at the time I took the screen shot, there was two issues, but I have about 10 issues in there now of things that I just kind of want to continue to enhance and improve and just kind of keep this out there as a proof of concept for a design system or a toolkit. Okay, so yeah, we're gonna walk through that in a second. Let's see, this is so weird. Okay, so anyway, so one thing about Storybook is that it was originally built for React. And it's got those other kind of first class JavaScript libraries, I think Vue, there was a few others maybe spells in there, but most of the documentation on their website is for React. A lot of it still applies to this, but some of it does not. So I'm gonna kind of talk through what to look out for and the things that don't apply. So the things that do apply are the args. So we'll talk about that a sec, but args are basically the props. Args, the parameters, it's how you can set some stuff in Storybook in terms of for previewing purposes, decorators, same thing, you can wrap stuff in Storybook. You can wrap Storybook and other code like HTML styles, whatnot, but you don't want it to be shipped with your actual components. The naming components and hierarchy, how that all is done, writing the docs, and then just the general Storybook configuration, which is in the dot storybook folder. All that stuff is relevant if regardless if you're using the React version or this HTML twig packed version. Yeah. I might have totally misunderstood what you just said, but you said you don't want it to be shipped with your actual components. I have no idea what that means. Okay, so when we package up the components, we're gonna package up some twig files, JavaScript, and CSS. There may be some tweaks you wanna do to change how it's displayed in Storybook, but you don't want actually to be part of the component that the website uses. I'll show you, I'll leave you an example in there. Yeah, the backgrounds and stuff. Yeah, so those, you can wrap them in a thing called decorators. Yeah. Okay, so. So, the big thing you do in Storybook is you write stories and it's a JavaScript file. And most of what is in the documentation is also correct. But there's one thing that's not. So if you look at this first line here, let's see. Yeah, so if you look here, I know it's kinda hard to read and I can, when we go to the code, I can zoom it up. But basically, this top line, the syntax is specific to our implementation. In the React one, you basically render the component and pass your args in. You just have to do it slightly differently for twig. And, but everything below that dotted line, this is all normal Storybook stuff that you'll be able to find in the documentation. None of it's changed. So, okay, we are now at the point. So I'm gonna actually go to the hosted version of Storybook, I don't think there's any more. And, okay, so I put together this sample project. So this is Storybook, basically. Can you bump it up a little bit? I can try to do that, yes. Does that work? A little bigger, please. Eric, come on. Okay, a little bigger. Are we good? This is good. Good for the first row. Okay, that's all we need right now. Okay, so this is where I'm old fashioned, I'm gonna use my wallpaper here. So basically, I'm just gonna kind of, oh, we got time. Okay, I'm just gonna go down through here and just kind of explain what's going on. And when we get to some of the components, I will walk through some component controls. So I put together some documentation. And this is all specific to this installation or this version project here. And so I'm not gonna go through all the details, but it's basically, I'm just gonna hit the high levels and tell you what's in here. So basically how to configure your theme or your site, depending if you have a theme as a separate repo or just built right into the site repo. I've got instructions for both, how to do it with Composer. Obviously for MPM, you would just do it differently, but it would be very similar. So that explains that here. And then it just kind of how to set up your theme or, I'm sorry, this is just the installer installation. Yep, just explain stuff. This is kind of the big one. So how to set up your theme. This is like recommendations. Again, the whole idea of this project is to get away from the super opinionated. The ones that are already out there. So I'm not gonna tell you exactly what to do, but I'm gonna tell you what this project is doing. So yeah, so basically telling you how to create your theme. But basically you wanna create your theme from scratch. Probably just use stable nine as your base. And then it just tells you how to add the libraries. Most people would just figure, I don't wanna say most. Some people could just figure this out on their own, but I want it to be very explicit and walk you through it. So that's what this documentation is for. And we're talking, in this case, adding global libraries. Add it to CK Editor, blah, blah, blah. And then basically talking you through the theme files that you need to create. And some helpful pre-process functions that will just kinda help in general. Some of these apply, even if you weren't using the toolkit, just some helpful pre-process functions in a Drupal theme. And just an idea for a block HTML template where we can easily add our twig templates to it. Sorry that this is very hard to read. But I'll be happy to talk through any of this afterwards. And then this is the good stuff. This is particular to how to use this with Drupal, basically. So those four things I mentioned before in terms of the four big things you have to do, that kinda goes hand in hand with this. This is like, once you've got that all set up, this is how you would actually use this in Drupal. Again, it's hard to read, maybe it isn't. Oh, not too bad. Basically, I'm just kinda talking you through some scenarios in here where you could, we're going with the approach of worshiping these twig templates to you, and you're gonna embed them instead of recreating them in your Drupal theme. If any of those of you who used pattern lab back in the day, that was kinda what you did. You imported them, you used include embed, extends depending on the situation to get them in. That's what we're doing here. So we're basically gonna say, we're gonna import them into our twig files, themes twig files, and then we're going to pass in our data as we come through. So we basically map the properties in the twig file we're bringing in, map them to actual Drupal data. So it's a colon here, it's still like a one to one key value situation. Yeah, there's another way to do it. Sometimes you don't need, sometimes you don't need to actually use the twig template. Sometimes you just need to apply a class. And so, a button is a good example where you might, you don't wanna recreate the wheel that Drupal already provides to you. So sometimes you just wanna add classes instead of pulling in the whole template. You might see that more with very primitive elements, sometimes a form elements. You don't wanna rewrite the form API, you just kinda wanna use what they have there, tweak it a bit. And then basically each component is gonna have its own specific instructions for how to use with Drupal. This last section is basically, how do you write these components in a way that's good for your Drupal site? Because the story about, like I said, it's just to display things. We actually wanna write it in a way that Drupal wants. And so in Storybook we're just kind of switching things around to make it work on the screen or on the browser. So my first tip we'll call is to just basically create sample data in the same way that it would be in Drupal. So, if a thing is an object in Drupal, like links or images or something, create the sample storybook data that way rather than surgically putting them together at some point in the function. You can just kinda start out that way. One of Drupal's argument types is an object, so you can just do that. They also have arrays as well. Another thing is you could emulate Drupal attributes as you're writing the components. So, for example, can you see this? I wanna get a little bigger even. So, for example, if you don't want to rewrite your template from scratch and you wanna be able to, but you wanna use what Drupal is giving you. So if you don't wanna have to rewrite everything and then remap everything, so you can actually simulate attributes and storybook. There's a package. There's a couple out there by different people. There's a Drupal attribute emulator. Let's see who's I'm using. This is an old one. I think it's, yeah. I think Rob Loesch maybe did it, but it's an old one and it's still useful, so, yeah. In terms of attributes you're just meaning like HTML attributes. No, like the function, I'm sorry, the Drupal function or the Drupal attribute object. Oh, the attribute object. Yeah, yeah. Yeah, actually attributes you can actually, those are even easier if you just plop those in. All right, where was that? Yeah, so if you wanna replicate the Drupal attributes. So this is an example of the text. I just grabbed the text area component out of, I don't know, use the other core or stable nine. But basically they have wrapper attributes and then they also had text area with attributes. And so we went in, in this, we went in and basically added the ad class and set attributes right in our template that's here in Storybook. And we basically, we emulated that in Storybook. And so, because this right here is in a format that Drupal wants. If I didn't do anything in Storybook or use that function that I just showed you on MPM, if I didn't do any of that, this would not render in Storybook, like how you think it would. So we're basically, I'm gonna just keep hitting this point over the head, but basically make it work for Drupal and then kind of finesse Storybook to show it. Yeah, so the Drupal attributes. So basically you would just import that function at the top of your Story page and then simulate. And then you basically, these two here, you're just instantiating a new version of that. And there you go. And then this is just a little anal tidiness thing. You could actually, when you use the Drupal attributes thing, you just want to hide it from your Storybook or it serves no purpose. So this is just a tip to do that. Yes, sir. Do they have, like I know the Twig has a whole bunch of like those functions to do capitalization and other things, do they have simulators for that as well or do you have to kind of build your own? Everything that's in the native Twig spec will be there. We're basically using a JavaScript version of Twig. All those will be there and then the Drupal specific ones we've imported as a package. And then the other thing, this is kind of where there's a few instances where you actually need to change your code a little bit. You want to conditionally render things for Storybook. Sometimes there's not tips or tricks to make it work in both. So a trick I've used a lot is if you look at the DB is active variable that's in Drupal, that's not in Storybook. Unless you explicitly set it, it will not be in Storybook. So that's a way, I don't know if this is proper, but this is a way that you could actually tell Storybook or tell your Twig file whether it's in Storybook or it's in Drupal. And so a good use case of this is somewhere that you're gonna use formatted text in Drupal. And you don't want to have to go recreate that whole object in Storybook even though you can. You can actually just do a if thing, if statement here. So if not DB is active, it means you're in Storybook and you're not in Drupal, you can actually wrap this body text with P tags or whatever you want. But if you're in Drupal, you're gonna let Drupal handle all that, all the stuff that comes with the formatted text field. You want them to handle that. So this is a use case where you might want to use that variable. There are more extreme use cases where you wanna actually have a slightly different local file or a local Twig file for Storybook than you do for Drupal. And it's not the cleanest solution, but sometimes it's what you wanna do. And so I just kind of explain that here. And I have the way the package gets compiled is anything, any Twig files without local in the name do not get shipped with the completed package. So you're basically creating two versions, one that is slightly different. All right, any, I probably did this a little bit out of bored, I probably should have showed you guys more about Storybook, but we're gonna do that now. And so how I've organized this particular project is I put it into five sections. So I have my documentation, so this is all stuff that's just docs. Then I, do you have another question? I just wanna know what's making your document system is really nice. MDX, so this is all Storybook, MDX files. So yeah, I'm thinking, yeah, let me bust through this and then I'll see if we can actually see some code on the screen. Okay, so then foundations. This, I'm just gonna breeze through these real quick because this is not what this is about. That would be more about how to organize your design system, but in my particular case, if you wanna use this tool, foundations are basically HTML elements that I want to style, but I don't want to ship a Twig file. There's gonna be no JavaScript. It's just, I want a style thing. So here's an A tag, here are the headings, here's a paragraph, but obviously this is not comprehensive, but when we get in here, I'll start to show you some of the Storybook controls. So if you look at headings, let's go down a step here. This is an idea of what I say, the args table or arguments. We've basically told Storybook, we want these to be arguments. We want it to have a heading level of one to six and let the user preview what they want. So we have this little slider here, so that's an H2, H3, so on. You can show the code at the time as it's happening. So if I go back up, it's an H1. If I go down, the code changes to H2, so this just kind of shows you what's going on behind the scenes. And then here's a text field, so I could just say, whatever. You can kind of see this in real time to see how long of a headline you might want. It's great for buttons to see how long is too long for a button and stuff like that. Okay, so the next section, utilities. These are utility classes, concepts, ideas, mix-ins, whatever. Anything like that goes in this section. These do not get ship twig files. They're not components, like capital C components. They're just, it's a way for us to bake in the styles here, bake in sort of functionality, or just display to you the user what's available. So like for example, this color is, well the breakpoints, I'll go through it. Breakpoint one is basically how to use the breakpoints mix-in. The colors are basically taking my CSS props and just displaying them so you can see what they look like. A design system, no, no, is to actually put the colors, the actual colors in there, because you just want the colors to have more of a purpose. So you just want color names, but sometimes you want to see what they look like. So this particular story doesn't provide anything. It doesn't provide CSS or anything like that. It just shows you that these variables are here for you to use. So the next one is container. Let's skip that. Grid, people like grids. This is a grid. It shows you how to use the grid. And you can kind of sample things through the arguments here. So you say, hey, I want this one to be six columns, maybe, and then it updates here. But obviously that's too many, so we want to maybe bring this one down to two. So it's kind of like real-life editing in the arguments here. Okay. All right. We're gonna skip over components, because that's the real stuff. The last category we put in here is recipes. And this is what my colleague and I are also using at Pantheon as well, is in this recipes category. And so this is basically, we're not shipping these as components. We're telling people how to put together our components and make things that they may want to make. So this is a card grid. So we've basically taken the card component and mashed it with the grid utilities and displayed it here. But this is a great place to put, like if you have a teaser page or you want to make a mock-up of the front page. Stuff like that is great in this recipe section. You're not shipping any code out of it. This is merely just to preview it here. At the bulk of the stuff, the magic happens here in components. So these are the things that are actually, all these styles, any JavaScript related stuff gets compiled into the main JavaScript. Any CSS gets compiled and the Twig files get shipped. Anything in this section, the Twig files are available for you to use in your theme. And I know, it's in the documentation somewhere, but I don't think I mentioned it yet, is we want to use the components module. You guys familiar with that components module? And it's going to let you name space the stuff coming out of here for really easy usage in your theme. Okay, so I'm just going to walk through some examples. This is definitely not a comprehensive design system, but I'm going to walk through a couple of different types of components. This one in particular is the icon. We basically made SVG icons into code, because they are, and through via storybook you can kind of preview. So I can click, oh, I want to see the symbol info one or simple info error. I can just see the display there. And then we have four standardized sizes of it. So you can see what it would look like in large. And then this basically shows you how to use it in twig, so you would include, all the icons are in one twig file, and then you basically pass the name if you wanted to pass the size and not use the default, you could pass that as a second item there under that, under symbol search there. So yeah, this is a great way to just have all your, all your SVG icons in one file. Okay, let's see what we got here. So button, button is kind of the base level. Like if when you install Storybook, it comes with a button. It comes with like a button header and maybe like a page and it kind of shows you how things add on to each other. But this is a great example of what to look at here in terms of how Storybook works. So I'm gonna show the code right now. This is a base code, it's a, I'll read it just in case you can't see it. It's a button type button, class SV button, text as button. If we change any of this, it'll change the code and change the live display. So we can say a button with long text. We can change it to a secondary button. It's our alternative button style. This is all live, so you can see any sort of hover states. You can see focus states, all this right in here. You can change the button type. It's not gonna look different, but the type will change in code. It can either submit button or reset button. And then it can be disabled button. So all this stuff is useful to preview right in here. And so we're gonna get back to your question from before, is this is a good example of why you might wanna change something slightly for the display here. This is not using decorators, it's just using Storybook parameters, but the reverse button, if I were to click reverse button up here, and not make it, you can't see it because it's on a white background. But we can kind of preset these stories. You can see, hey, what if this button, reverse button were on a dark background? There you go. And so we can kind of set up these secondary stories to the primary one. Okay, but what if you wanna play around with the arguments on those? You can actually go to the canvas over here. And it lets you, there's the docs, which shows all of the stories within that group. And then canvas shows each individual story. So if I go back to button default, I can look at, see what it looks like on different colored backgrounds. And so these are all built right in the Storybook. These are all in the docs. We don't have to hack anything specific for a Drupal or Twig. But you can set break points. You can set, like if your design system has certain break points, you can preset those. Or if you have certain background colors that you use for everything. So I'm gonna go ahead and say, if this is on primary lightest, this is how the button would look on that background. Or if I wanna see the button reverse, obviously it's not gonna pass accessibility on this background. So let's see what it looks like on the primary dark background. Yes, great. So this lets you preview those types of things in real time right here. There's a concept in Storybook called add-ons. These first two are built in. These last two are add-ons. So accessibility lets you do accessibility tests. This one passed. So it's not gonna have anything bad. But if it did, it would tell you what didn't pass and where it was located. And this is just kind of, like I don't have it on this project, but in my real work, we actually have automated accessibility testing as the project, as it's getting built. We don't have that here, but this is kind of like the first line of defense. Before you even make the commit, you check it here and then your automated testing might catch something different or if you didn't see it here. But yeah, so that's great. And then the other one is the source code plugin. It's not great for the button, and I haven't really formatted this in any way, but because we're using the Storybook HTML version and I haven't hacked it in a way that lets us show twig here, it just shows the rendered code. If someone actually just wants to look at the twig, we have this plugin here that you can just actually see what the actual twig code looks like. But they wouldn't use that, right? They can if they want, but I would recommend using the template that got shipped with it because if any updates are made in the design system, especially if different people are working on it, it's not gonna be efficient. They're gonna have to go in and redo their code. But yeah, it's just here. If you're curious or you wanna use it that way, one of the things that is being done at Pantheon, I think by the people that are consuming the toolkit is we have a couple of different versions of a hero. And for the end user experience, they don't want, as the person's building this site, they don't want them to have to check, oh, I wanna use this particular hero. I wanna, you know, we're actually combining two of my templates into one of theirs. And there's like a boolean like, hey, which version of the hero do you wanna use? So there's, yeah, yeah. Yeah, so there's ways you can do this. So I'm gonna walk, we got a few minutes, I got a checklist. So we talked about controls, campus, viewports, all that stuff. So I'm gonna show you how it can be built upon each other. So we already saw that card grid, but let's go back. Here's the card by itself. Oh, it's not, we don't want it on green, we want it to reset the arcs. There we go. So this is huge, but yeah, here's the card. And it's using other parts of the design system, or the toolkit. So here is the heading we saw in the foundations. Here's the paragraph we saw in the foundations. Here's the link, which we didn't look at, but it's a component. And so all these are being composed into the card. If we were to look at the code for this, here's where this comes in handy, I'm actually pulling in the link component right here. So you're basically saying, hey, I wanna use the link from another folder in this toolkit, and we're gonna plop it right in so you don't have to recreate any of that. And you'll see that all over the place and in systems like this. Okay. Anything, anything here? Well, let me pop back to the slides real quick. And then if we have time, I can, I have this, like if we have time kind of thing. So bonus topics. So a custom component generator. So I actually built one for this. It's hosted separately. It's very particular to this. And it's already imported into this project. But it's very specific to this, because let me make it bigger here. Because it knows my folder structure with the whole foundations, recipes, components. And then based on what I tell them, where I tell them what folder to put that in, it also knows what kind of files to create. So like for recipes, we're not creating a CSS or JavaScript. For components, we're creating all of this stuff. Stuff like that. So this generator's here. It's a Yeoman generator. It's maybe a little old school for some. But there's also a more modern thing called PLOP. It's a JavaScript one. You could build a generator in that as well. But this is already integrated in the project if you choose to fork the project I already have. And then what else we got here? So that's, these are just kind of bonus topics that I knew I wouldn't have time to go into, but wanted to mention. Platform agnostic design tokens. There's a, has anyone used style dictionary? It's fantastic. It's linked here. You basically create one set of design tokens regardless of what your platform and then you tell it how you want it to output. So we're outputting CSS props, SAS variables and a JSON version that we consume and react, JSON design tokens. There's all these other ones you can do. But it's really great if you have, if you are using different systems and different frameworks. So that's there. Question? Yeah, how do you handle library dependencies with the exported templates? Do you add the dependencies in the template or do you just use one global? Like what, for example? So like let's say you have a card and it has like specific card styles and in your theme you want to define a card library. Do you do that in the twig template in your exported code or do you do that for each component? You could do it either way. I'm doing it globally. So I'm doing a global compiled CSS and a JavaScript in this. But you could do it separately. It's basically however you script your stuff to ship. And so you could ship different JavaScript files for each one. You could require them individually on twig. In this particular use case, it's just a global. I only have two components that use JavaScript behaviors at this point. But if that was heavier, you might want to do it on a template by template basis. Automated VR and accessibility testing could be done via Playwright and Axe Core. I don't have that in here yet. Testing and approval workflows via Chromatic. Chromatic is a product from the storybook people. It basically runs CI and lets you preview the stuff. It's great if you're working with developers or sorry, designers that you want to see the live stuff and get approval beforehand. I'm not using this. We're actually gonna use Pantheon front end sites with ours and let people see PR pull requests versions of Storybook. That's how our designers are gonna look at it and improve things. But Chromatic's a great tool. I've used it on my own. And then Storybook Connect. I cannot vouch for any of this, but I highly recommend Figma as your design tool because you can basically set up your components to match what you're doing with the ARGs in Storybook. You can set the Storybook or Figma component variance to match this exactly until you have your designers and your developers are seeing the same thing. I haven't used this plugin. I know it exists. And then that's just kind of what I just said about replicating that. I am right at time. I can definitely answer more questions or show you guys things not in the dark out there or whatever if there's any specific questions. This is, there we go. Keynotes being wonky, but yeah. So that's my contact info. Here's a link to the project. I'm gonna try to, yeah. Yeah, I don't know how we're using the new system this year.