 All right, I guess we'll get going. Thanks, everybody, for coming out. This is external design systems in practice. I was asked a couple of minutes ago if I wanted to have everybody move up. I feel like everybody who made it here at the end of the day deserves to sit wherever they want. So congratulations. Yes, that's right. So there's a little link to the slides, the Bitly link, external DS-AMS, if you want the slides or some resources. They're online. So enjoy. I am Brian Perry. I'm a lead front-end developer at a company called Bounteous. I live in the Chicago suburbs in the US. I think I've gotten past my jet lag, but we'll find out right now. And I'm a lover of all things component-based and component-driven, so building with components in Drupal and design systems and tools like Pattern Lab and Storybook, and increasingly building with component-based JavaScript frameworks like React. And I'm also a lover of all things Nintendo. So if you want to track me down and talk about the cool games you're playing on your Switch, by all means, I'm playing Fire Emblem, and then also started Return of the Obra Dan on the Flight Out Here, which is like a murder mystery game. It's really great. And I'm available on the internet in a variety of places and would love to internet with you. And as I mentioned, I work at a company called Bounteous. First and foremost, I want to thank them graciously for sending me out here. A little bit more of a haul than usual coming out to Amsterdam. We have offices throughout North America. Drupal is one of a handful of things that we do, but I get to work with a great Drupal team and learn so much from the folks that I work with. We're often hiring, so if you're looking to do great Drupal work, get in touch. And also if you're looking to have great Drupal work done, I can get you in touch as well. But if you happen to have, if you know me or happen to have seen me speak, you might be familiar with me working for a company called HS2 Solutions. I did not quit. HS2 Solutions about a year ago rebranded as Bounteous. And the reason I mention that is because it's kind of the jumping off point into the first of a couple things that we'll be focusing on in the time that we have. So our rebranding process, and specifically the things that having what we call the design system repository that was an external dependency of the project, what that brought to our rebranding and our rebuild. And then later on, after we look at this from more of a traditional CMS architecture, the second half, we'll look at some of these concepts applied to a progressively decoupled build as well. So but starting with the rebranding. So this is our old HS2 Solutions website on the left and the new concept for Bounteous site on the right. And we had a brand launch that was targeted for November 5, 2018, just about a year ago. And although it didn't feel like it to me necessarily leading the website rebuild effort, the website was just part of a larger coordinated effort. Things like press releases and new business cards, email addresses, notifying our client base, things like that. And then also as part of this process, contributing to why we were rebranding, we had a number of acquisitions. So there were a few different sites that we were migrating into our new Drupal 8 build. The existing HS2 Solutions site was in Drupal 7. And then Lunametrics and Infill Digital both had WordPress sites. We were specifically focusing on mostly the blog content, especially Lunametrics, they had years and years of great blog content that we wanted to be able to live on. And Nate took the lead on the migrations. So it was working in our new Drupal 8 repository, working on migrations, having that content land in this new instance. And then meanwhile, Leon on our XD team is starting to work on initial wireframes and early concepts of what this site could look like in Sketch and sharing things in Envision. And I'm doing my best to follow alongside him and do prototyping in the browser using Pattern Lab as a tool. So seeing what things actually look like in a browser, giving a chance to be hands-on with non-traditional device widths that we might not have wireframes for, things like that. And then as the concept kind of solidifies, Jolene took the lead on higher fidelity prototypes, but I continued to follow along in that Pattern Lab instance, building out these concepts and some supporting components all in Pattern Lab. So that kind of brings us to the point where we have this design system, we're calling a design system repository with these prototypes and some components that we can reuse. And then also the Drupal instance where we start to have content from the existing sites land in there. So we need to consider exactly how we're gonna integrate those two things together. And or what I'm gonna use kind of a somewhat ridiculous example to describe where we wanna put the mustard. So I also wasn't sure coming out here if mayonnaise was just like a gross thing in the US, but it's also a gross thing around here I've confirmed. But the two kind of cases we'll be talking about here is the mustard and is case on the left hand side. There's the screenshot from a sketch comedy show, one big jar with mustard and mayonnaise combined in one place versus having your mustard and your mayonnaise, your condiments separate that you can choose to do with as you see fit. So the combined mustard and mayonnaise approach is kind of what I had been doing on projects up until this point. So Pattern Lab or some sort of pattern library tool embedded in a Drupal theme. Also pretty common in component-based themes in the community, even in the contrib space as well. So some advantages and disadvantages to that approach. It's theoretically easier for Drupal to get at your components because they're right there in your theme in that approach. In some ways that's also gonna simplify the build process. And for developers who might not be familiar with this component-based approach, it's a little bit easier for them to wrap their heads around and understand. They look in the theme, the theme things are there, they can change them and see the intended effects. But also at the same time, having that tightly coupled like that, it's prone to Drupal-specific things finding their way into these components. And it depends on your project and how this is gonna be used, whether or not that is actually a problem or not. But it may be. And then on the other side of keeping the projects independent, that's kind of where we were at this point in time on this project. We had that separate design system repository and a separate Drupal repository. And in theory, that is gonna promote reuse beyond just a single Drupal project that it's embedded in. Could be multiple Drupal projects or themes that it's used on or potentially even beyond just Drupal. So we had to come to a conclusion about exactly what we're gonna do, where we're gonna put the mustard in this case. And we decided to keep the mustard and mayonnaise separate, not this Heinz-Mayo-Must, which is actually a thing you can buy in US grocery stores, pre-combined mayonnaise and mustard for people who are really busy, apparently. But some of the rationale behind this decision, again, it potentially keeps the components more Drupal-agnostic or CMS-agnostic. I think it also encourages prototyping. So when things are tightly coupled within a Drupal theme, I find that people tend to stand things up in Drupal to see what they might look like or what changes might look like. And if it's a separate project with separate tooling, I think people tend to take advantage of lightweight prototyping more frequently. And it already was a separate project at this point, so it's kind of the path of least resistance. Some other gut feelings that go into it, it's always kind of conceptually felt like the right approach to me, even if it wasn't what I actually did. And it was also advocated by many in the community, whose opinions I trust, which is a great thing. And there was the suspicion that we might be able to reuse these components on other web projects related to our brand, although there weren't any hard requirements at the start of this project. And it also felt right for our company and the diverse skills of our company. All these people are not developers and not all of them are front-end developers, but many of them are. And of those front-end developers, some of them don't have experience with Drupal. Some of them specifically do not care about Drupal, believe it or not here at DrupalCon. But having this set up in such a way that people who can just write good HTML, CSS, and JavaScript, more front-end developers throughout our company could contribute to our website, seemed like a really positive thing. So now that we landed on that decision, let's talk a little bit about how it's actually structured and how we included this dependency. So in the design system repository, we just, so first off, worth mentioning, we're using the PHP version of Pattern Lab. This is about a year ago, so it's a composer dependency. In the design system, just created a simple composer.json file, giving it a name, a description, and then the installer type of design system, which we essentially just made up in this case. We'll see how that's used in a second. And then in the Drupal project, in the main composer.json file, had to do a couple things. So we had to add, in the repository section, our bit bucket git link in this case, right next to packages.drupal.org. And then in the extra section here, under, we added the installer type of design system so that it can be aware of this design system type that we defined. And then under installer paths, we specify where something of a type design system is gonna go. So for a Drupal composer project, it'll move modules into, modules can trip, things like that, based on this as well. Whoops. We put it in a library directory inside of the theme, hopefully indicating that it's a hands-off dependency. A lot of other things we could have done there. We looked at just keeping it in the vendor directory, but found that it was, in some cases, challenging to reach deep into the vendor directory to get things like templates in a theme. So that's where we landed on that. And then that allows us to, composer require the design system repository. So leading up to the pre-launch cycle, we required things at dev, things were moving pretty fast. And then also it allows us to, in the Drupal project, run composer update. So we have control as to when new and updated versions of the design system are going to be part of the theme. And also we can tag releases in the design system so we can require it a specific release, rollback to a release, all that good stuff. And then actually, so now that we have the dependency available, how we incorporate it into the theme, if you're familiar with component-based theme approach, there's probably nothing all that new here, but in our libraries.yaml file, we created a global library that had our compiled assets. So a compiled CSS file, our JavaScript bundles from Webpack. And then using the components module, created some twig namespaces so it could have access to the templates from our design system and also give us some shortcuts, following kind of the structure of our naming convention, not quite the default atomic design naming, but in the neighborhood. So now that we have the dependency available and incorporate it into our theme, a workflow that we kind of fell into with the folks that we had working on the project. So we had Sean, who can certainly do Drupal things, but is another developer who I think is often, his best self, writing great, just general HTML, CSS and JavaScript. So he worked on a bunch of the remaining components in the design system repository. So without him, we probably wouldn't have had a theme, but he only ended up having two commits in the Drupal repository. And then Wade kind of played the middleman integrating these components into Drupal. So he was wiring up the design system components to content in Drupal, adding things to layouts and layout builder. And most of his effort was in the Drupal repository, but he would make some changes in the design system if there were things that weren't considered on the Drupal side, or some refactoring to make his life a little bit easier. And in general, we found that that workflow, at least with a team that we have worked pretty nicely, leading up to the launch. So as is often the case in any project, we found some scope-related surprises as we went along. But specifically ones that having this design system dependency opened up some really interesting possibilities. So the first is the existing Lunar Metrics site. Lunar Metrics now Bounteous offers trainings through North America for Google Analytics, Google Tag Manager, the general Google suite. And they had a training section of their site that would list the upcoming trainings and also allow people to sign up and register. And we came to the conclusion that we weren't gonna be able to re-implement this functionality in time for our date, also because there were some changes and new features that were just recently added to the site. So what we decided we were going to do is keep the WordPress site alive at a subdomain trading.bounteous.com and make it match the look and feel of our new Drupal 8 site. And I don't know that that would have really been a realistic option if we didn't have these components ready to go and be used in another system. And I also don't know if it would even be something that we would have considered in the first place. So the WordPress integration, we worked with a company called Wallya Creative to handle this re-theming. They did the initial theme for the Lunar Metrics site, so it was great to have people who are already familiar with what was there. And they actually introduced us, or at least me, to the Timber plug-in for WordPress. And that allows you to use twig in WordPress, which is certainly handy, given we had all these twig components. I love their slogan here because WordPress is awesome, but the loop isn't, which personally is something I agree with. So they created an initial prototype using the components from the design system and Timber to stand things up pretty quickly and prove that we really were gonna be able to create something that matches the look and feel of the Drupal 8 site that we were building. So just a little bit on how that actually works. So this is a look at the training landing page and there's a list of all the upcoming trainings, so training items in this case. Then in the training module, that PHP template here, we've got a wrapping div with a parent class and then a for loop that goes through, in this case, course data and assembles these training elements, specifying the event data that we want passing into an array here. Not unlike some of the things we might be assembling in a twig template or prepping things for a render array. And then in the trainingelement.php template, we're just saying if there is data, we're calling timber render, specifying the template that we wanna pass it through from the design system and passing in the data. And that ends us giving us all of the upcoming trainings using the same twig components from the design system. So we were able to create a version of the training page using keeping WordPress where it was, something that really did match the look and feel for our main Drupal 8 site really nicely, included in the main navigation and everything. If you're looking at the address bar, obviously you'll know you're going some place else and you should be looking at the address bar, but hopefully visually it's pretty seamless. And then another surprise, really close to launch, we found out that DMACC Media in Toronto was also going to be joining the Bounteous family and we wanted to rebrand their site as Bounteous.ca for a variety of reasons, including the timeline. We knew that this was gonna be a smaller scale effort. It wasn't gonna match one to one, but we still wanted to be able to have a lot of the elements of this new brand. And having the design system repository in this case also really helped the conversation. The first call where we got the developers together, I was able to say we have this repository calling it the design system, here's what's in it, here's the tools that are available, and you can use that however you see fit to make this challenging timeline possible. And ended up being a lot more of a kind of manual selective process, picking and choosing classes and borrowing some markup. There were some assets that they used wholesale, but still gave us something that had a lot of the feel of our new brand and our new site. So we made our November 5th date, everybody took a very long nap, and after that we kind of rolled into our post-launch reality. So at this point I am kind of ramping off of the day-to-day, and other developers in this case Kyle and Steve are coming on to help out. And at this point the majority of what is coming their way is really Drupal specific. So bug fixes, things that didn't make the initial scope, but they're doing the vast majority of their work in Drupal. And putting words in their mouth a little bit here, but faced with the design system, that dependency and the kind of slightly different setup here, they're probably wondering why can't I just Drupal things? Why can't I just reach into the theme? Why do I have to make a commit over here and pull in the composer dependency and all that good stuff? So some lessons learned from that. One is that documentation is really important here. I think we did a decent job of documenting the how, like what the process actually looked like, where you make changes, how you pull them in. But in hindsight it really would have helped to have more around the why. So why are we taking this approach? What advantages does it bring us? What are the other contexts outside of Drupal that it's being used? And what are some of the challenges that we envision? I think that would have changed the conversation a little bit, maybe reduced some frustration. Also became increasingly apparent that it was important to have a really efficient workflow to be able to experiment in the context of your particular CMS. Thankfully got this in place before others came on, but in this case it was a pretty simple set of gulp tasks that copy things over so you could make changes locally, see what they looked like before committing them over to the design system. Since then saw some other approaches to this. So there's a composer package that lets you do like local linking of a dependency so you can do local development and try out changes that way. Now we'd probably be using the node version of pattern lab and node has the npm link feature which lets you sim link a version of a dependency and then swap back to the published version of a package. So that's probably how I'd approach that. We also found that it was increasingly important to be really strict about versioning. We mentioned that we were kind of requiring it head leading up to launch, past launch that obviously did not scale especially as we were juggling some pretty divergent branches with new functionality so we really needed to get better with tagging our releases and pull them in so that we prevented things that landed early in the design system for to make their way into the Drupal repository unexpectedly. And all this is to say that this external approach does add some overhead. So it's a cost that you have to weigh. I think for this project, it definitely had a worthwhile benefits. And then kind of one other thing that we saw is we saw the lines between the CMSs blur in this case. So take the training items and say that we added a hover effect, Kristen testing in QA and John a marketing who manages the training sites. They would expect if we take on a ticket for that the change that happens on the Drupal homepage would also apply on the training landing page in WordPress. And we saw some cases where that didn't happen. It did some kind of traditional WordPress theming to get us across that finish line. So after launch, we came back and refactored things and used more of that timber approach to be able to use the components as they stood and make it a little bit easier to pull in the design system dependency into WordPress so that more often than not, one change would really apply in both cases. So that's kind of an overview of that approach with traditional CMS and our rebranding efforts. Now with the remaining time that we have, we'll talk a little bit about some of these concepts and attempting to apply them in a decoupled build. Specifically looking at situations where you're not sharing a template engine, you can't just use twig everywhere necessarily. So we're gonna look at a progressively decoupled project at a pretty high level, still an ongoing project. But on the Drupal side, we have a element of this, it's a traditional Drupal build, but we're also providing APIs to React, default JSON API endpoints and also some custom JSON API endpoints. And then on the React side, it's consuming those Drupal APIs and essentially providing an authenticated user portal. So then the context of both things combined, there's traditional Drupal content, but then also a names-based route owned by React and that user portal. So that also presents a number of different developer contexts here as well. So there's Drupal developers in the portion of the Drupal implementation that really isn't going to be interacting with React at all. On the React side, we wanted to make sure that our React developers kind of had the development experience that they are used to. So we wanted to make it easier for them to be able to develop in isolation without having to spin up Drupal environment. So some of that was accomplished through mocking services. Some of it was environment variables to use our development or staging Drupal environments as APIs. We also wanted to make sure they had their hot module replacement so their changes are reflected automatically in the browser. But of course, there is the very important context of the real world integration of the portions of the site where Drupal and React are working together and overlapping. So then looking at templating and styles, Drupal obviously uses Twig. The Drupal portion of the project did have some of its own unique styles and components. React is using JSX and did have some of its own unique styles and components. But then in the overlap, there were definitely global styles that applied everywhere. But we did, we were wondering initially if there were going to be a lot of components that we need to use in both places. We found that there weren't too many of them. And so far it really hasn't been enough that we've been willing to take on the effort trying to tackle and solve that problem of literally using the same component in both places. We'll talk a little bit about what we think that might look like. But we still had a lot of styles that were shared between and we wanted to be able to use it in all of the different contexts. So we started wondering if something like a design system, something that lives in the middle could serve these projects and handle those global styles. So we were considering how we might be able to approach that. Also around the same time, the continued debate around CSS and JS rages on as it does to this day. But also around that time, I was hearing a lot about CSS modules as an approach to this. John Albin had a great talk in Drupalcon Seattle, giving an overview of the CSS and JS solutions, but kind of zeroing in on some of the advantages of CSS modules. Gatsby ships with CSS module support out of the box, so I had the opportunity to use it in that context. I think Create React app also ships with support for it now as well. So just a little bit about CSS modules for anybody who might not be familiar with it. It's not a package in the way something like styled components or a motion, other popular CSS and JS, in this case React libraries are. It's something that's handled by the build process and a bundler like Webpack. It scopes the styles locally by default and we'll look a little bit about what that means. It also plays nicely with SAS, which was useful for our team and it has this nice super snarky logo where the modules and CSS modules overflows the container, ha ha. So think about Scope CSS. We will just look at this little side project about static sites. I created a little while back these card components. So here is a project card.module.scss file. The actual styles themselves, not particularly important here, but the general structure is the most relevant piece. So we have the parent class of project card and then we have the title, language, description class. We're also not explicitly using like a BEM naming convention here. We certainly could if we want, but the component scoping is also gonna handle some of that namespacing that sometimes people look to BEM for. And then in the component in projectcard.js here, we're importing styles from that project card module.css. And that gives us a styles object that we can use in our JSX. So you'll see that we have our div and then the class name prop. And at the top level, we're passing in styles.projectcard for that project card class. And then unsurprisingly styles.language, styles.title. And then if we actually look in a browser and inspect this component, what we get is this. So there's a combination of the module name, the class name, and then that kind of unique string tacked on to the end. And that's giving us a class that really is specific and scoped to this component. It's not gonna leak out elsewhere. You, unless you did something crazy, you also can't really reuse this class elsewhere either. So it's nice that it gives us a nice encapsulated styles to this component. But also, global CSS certainly has a home as well. And it can work in concert nicely with this approach as well. So this is a look, if we were just using a traditional SAS partial, doesn't have that dot module extension, which what helps webpack pick up on it. So if we just say import projectcard.css, that's gonna give us these styles in the global namespace. And then we can use the class name prop with just a string passed in rather than that object that we saw before. And these classes are classes that we can use elsewhere. And if they're written in such a way that they would cascade or apply outside of this component, they would. But obviously that it helps quite a bit for styles that are in fact intended to be global. So this is kind of the initial approach that we used with all this in mind. We had separate repositories for kind of these different pieces, these different contexts. You'll notice that since I say initial approach, it was not our final approach, spoiler alert. But so in the design system repository, we had a little Gatsby site that showed these global styles and context, and then allowed the different projects to pull these in as NPM dependencies and use those partials as they saw fit. So on the React side, things were imported in JavaScript with a mix of global and component scope. And then there was also some project-specific CSS as well. And then on the Drupal side, still using Webpack but creating one global CSS file that is a combination of design system partials and things that are specific to Drupal. So just looking a little bit about how that was consumed on the Drupal side. So in our package.json file here, we have just our Git repository for the design system, which allows us to pull that in. And then Webpack SAS loader, I think in this case, allows you to use a tilde for non-relative imports. And that's what lets us in this example on the right here, combine pulling in partials from node modules alongside partials from our Drupal theme as well. So again, we can kind of pick and choose the pieces that the Drupal theme needs. So as I alluded to, this approach was not all that well received by the team once we started running with it. Managing dependencies in this way was that the team found it tedious, so we had situations where we'd have to make multiple pull requests in different repositories and then have them all land at once for a single feature. We definitely found situations where people new to the project were a little bit unclear on where their changes needed to be made. Another thing motivating some of these decisions was trying to have that context for our React developers to be able to develop an isolation. And it's not explicitly necessary for that to stand on its own, for that to be possible, even in a shared repository that's certainly doable. But also, given it's a progressively decoupled project, at the end of the day, it's really just one website. So we adjusted to using a single repository. So we still had those shared styles, but the different contexts could, again, pull in what they need, but also use the tooling that was appropriate in their case. So on the React side, use CSS modules, as we talked about, and Storybook as a place to be able to see these components in context. And then on the Drupal side, Webpack to create our one CSS file and using Pattern Lab to show these things in context. And then you'll also notice that this is a little bit closer to that combined mayonnaise and mustard approach, the mayo must that we saw before. But it just happened to be what worked the best for this project in this particular group of people. So a few lessons learned. So not really specific to this project, but using a couple of different Webpack builds that were similar in some ways, but not exactly the same. Some quirks come out of that that can be a little bit of pain having things different. We talked a lot about the different approaches to this dependency, and it's really just a trade-off. So having multiple repositories does introduce overhead, but on the flip side, we found that going back to having a single repository can open the doors to regression. We saw more cases where a change on the React side has unintended changes elsewhere, and you have less control as to when these new global changes come in. And then also, the idea to not overdesign your design system, and this would certainly, in a lot of ways, be on me. But looking back on this, is this really a design system maybe a little too buzzword-excited here. It feels like something a little bit different. Shared styles or design tokens that we're using throughout the system that probably requires a different approach that, hopefully, we can recognize next time around. A few things that we aren't doing quite yet. So I touched on the fact that we're not actually reusing components in both places. Mostly, we just haven't found enough overlap to make the effort for that seem worthwhile. We have seen some small opportunities for shared JavaScript. And also, I haven't invested too heavily into that, but the main thing that we're doing when we identify that is trying to write JavaScript in those cases, using as much vanilla JavaScript as possible, which should at the very least make it easier to port some of that stuff over. And then to actually truly reuse the components here, it would probably require more JavaScript at the end of the day, at this particular point in time, either more React on the Drupal side or building things using web components and using those web components both in Drupal and React. Although I understand there are potentially some changes, challenges on the React side doing that, but I don't have a ton of experience. Although everything's in one repository, we're not taking a traditional monorepo approach, something like the Gatsby monorepo, for example, where it has individual packages published out of it that could be pulled in as needed. Or using a tool like Lerna, I think, is something that can help manage that monorepo dependency on the node side. So we haven't done that, but as we mentioned before, I think taking that approach would give us some more of that control that we lost out and we moved to a single repository. And we're using separate tools, pattern library-wise. We're not using Twig and React in a combined storybook. We did look at that initially, but didn't find a path to making that happen. Since then, there seems to have been a decent amount of movement in that area. At a couple days over the summer, some of the amazing folks gave a talk where they were using Twig in storybook with the HTML version of storybook. The latest version of the emulsify theme, I believe, also uses Twig in storybook. And then the next release, I believe, of storybook, they're targeting the ability to use multiple, I think what they call frameworks, in a single storybook. So going forward, this seems like it might be more of a viable option if we did want to have our Twig components and our React components side by side where we can see them together. So kind of coming to the end here, but based on these couple of examples, a question you might be asking yourself is what you should do if it makes sense to have a external design system dependency like this or where you should put your mustard. So some things to consider. You're probably not surprised to hear that there really isn't a black and white. All cases answer for this. But ask yourself if there is gonna be value in reusing these components. Sometimes though, it might be hard to know for sure. Like in the rebranding effort, we really didn't know that they were gonna be reused as much as they were. I'd also ask the role that prototyping, you want prototyping to play on this project. I think that having the pattern library design system less coupled can encourage rapid prototyping. You also have to ask how it's going to fit into your team's workflow and your team's makeup. Is it gonna allow more people to contribute? Is it going to make it harder for folks to participate? And then a couple things that have come up in past versions of this talk. So there's also the perspective of having, this is a separate dependency, as a way to help lock down your design system and give you more control over when things are published, when new versions are pulled in, things like that. And then also from the perspective of taking this component-based approach to building in Drupal, there's a whole set of challenges potentially with that, which would be a whole nother talk that many people have given, but I at least wanted to acknowledge that this talk doesn't really go into that at all. But yeah, at the end of the day, one particular muster does not fit all. I found that there are cases where having a separate dependency can be a great advantage, others where it might make more sense to have things a little bit more tightly coupled, more of the may or must approach. But at the end of the day, we're all trying to make a sandwich with our preferred condiments and making sure it doesn't fall over. So that's pretty much it. Definitely would encourage everybody to, on Thursday, go to the Contribution Day. I'm sure you've seen this slide a handful of times already, but always a fun effort, great way to give back to the project. And would love to have any feedback that you have on this session, either the session itself, you can go on the website and there's a survey, or there's a survey for DrupalCon Amsterdam as well. So we're pretty much up on time, might be able to sneak in a few questions if anybody has any. Also, I'll be around outside or at the conference, happy to talk more about this stuff. Thanks. If anybody has questions, we have these fancy boxes, but I don't see any questions yet. Oh, got one. All right, we'll get a box here. This working? Maybe part of a question and part of a suggestion. Instead of the mayo and the mustard, maybe mayo and ketchup, that's maybe a better combination. That's just because there's a little nuance in it, like you said. In some cases it works, in some cases it doesn't. Yep. I haven't really seen a lot of cases where we would approach this in this way, in my company, in the places I've worked, but it looks very interesting. But what I would ask is, how would you convince a company to invest in this approach, because at the start it's a lot of overhead, just like when you approach design systems in the general, because you have a lot of static content and static stuff that you have to add. So how would you approach trying to convince or to tell the team that this is a good way to do it, so the things they would have to look at? Yeah, honestly the great question, and also maybe we can make this ketchup instead of mustard, I'll get working on that. The biggest thing for me is probably reuse. If you are confident that there are gonna be situations where these things can be reused, I think this approach makes a lot more sense. Whether it be there's the more potentially extreme case of using the same components in Drupal and WordPress, but even having it not locked into one particular Drupal project, so if there really are opportunities to reuse maybe on similar sites, things like that, it could make sense, and then also from like an agency perspective, as a way to build reusable components that you might be able to use on multiple projects, there's definitely some possibilities there. But I would say that if you are really confident that these things will not be reused, it probably doesn't make sense. That's probably the biggest one that I consider. Awesome. Any other question, another one back there if you can pass the box. Thank you. What do you use for a local environment for such Smithshire containers or landowners? Yeah, I don't know that there was anything specific about our local environment that had to change based on this approach. For our Drupal projects, we use Drupal VM. So that's what we used, and yeah, that's about it. We didn't like spin up individual containers for the React side of things so people would be running node locally. That's what we did anyway. Any other questions? Again, it's the end of the day, the fact that you guys even made it here is wonderful in and of itself. All right, thanks. Happy to talk about this more if you have other questions, but thank you, have a good one.