Talking Drupal #416 Single Directory Components

 [MUSIC]



 Hi everyone,Stephen here. Before we get started with episode 416, I wanted to let you know that I had some technical difficulties, also known as user errors, during the production of the show which resulted in below standard audio for us. We've done our best to clean this up, and it doesn't take away from how good the information is from   Mike  and    Mateu So apologies to all who participated and who are listening. Let's move on with the show. This is Talking Drupal, we'll be the chat about web design development from a group of people with one thing in common, we love Drupal.



 This is episode 416, single directory components.



 On today's show, we're talking about single directory components in Drupal, how they differ from web components and what are their benefits with  Mateu Bosch and   Mike Herchel



 We'll also cover component libraries theme server as our module of the week. Welcome to Talking Drupal, our guests today are  Mateu Bosch and   Mike Herchel  Mateu is the admin of the Drupal.community Mastodon server, original author of the JSON API and single directory components core modules, and maintainer of more than 80 contrib modules.  Mateu welcome to the show.



 Thank you for having me. He's joined by none other than   Mike Herchel   Mike  is a senior front end developer at, say that for me   Mike .



 Angelina. Angelina, thank you. As well as a maintainer of Drupal cores CSS subsystem and default theme. He's a big believer in free open source software and the open web.   Mike Herchel welcome to the show. Thank you. And Angelina, we're hiring too. So if anyone is listening to this, check out our website and go there. All five of our listeners will apply.



 I should also say welcome back,   Mike , because   Mike  has joined us before. Yeah. For those of you that don't know, I'm JohnPicozzi solutions architect at E-PAM. And today my co-hosts are joining us for the next four weeks. Jen Lampton, owner at Generation Web Development. It's like a little.



 Jen's an open source advocate, web team and project lead, a Drupal provisional security team member. Backdrop CMS co-founder, an expert avocado surgeon, which we'll have to get into at some point, loves animals and likes houseplants.



 That's awesome. What is your favorite houseplant, Jen?



 Right now I have an Arabian sunset begonia that I grew from like a little tiny leaf cutting and it's massive. And so it's my favorite because it's doing the best. That's awesome. Yeah, I admittedly kill things. Well, let me rephrase that. I kill plants. So I'm into very maintenance things like orchids and I am not friends. I kill orchids too. I think there's a very special type of person. Maybe we can do a talking orchids at some point and talk all about that with an expert.



 So we actually have a special guest host today. Nick is off on vacation, hopefully relaxing and having some fun. Jumping in for him, filling his seat is Stephen Cross, founder of Talking Drupal. Hey, everyone. Glad to be here. You know, I think Nick has only missed two episodes in 10 years, 416 episodes. You know, that's pretty impressive. We won't let him forget it. How dare you. This is a show. This is a show that's going to go off the rails too.



 I can see him.



 It's already starting.



 Probably true. The New England Drupal community invites you to join us at Ned Camp, the New England Drupal Camp, celebrating its 10th year on November 17th and 18th in Providence, Rhode Island. Friday features trainings as well as an all-day higher education summit, and Saturday is a day full of sessions.



 Speaking of sessions, Ned Camp is accepting session and training submissions until September 25th. Visit nedcamp.org to submit your session or training topic, purchase tickets, and learn more about the camp. The New England Drupal community and Talking Drupal team hope to see you in November at Ned Camp. Thanks,   Mike . We look forward to seeing our listeners at Ned Camp. And now to talk about our module of the week, let's turn it over to Martin Anderson-Clutz, a senior solutions engineer at Acquia, and maintainer of a number of Drupal modules of his own. Martin, what do you have for us this week?



 Thanks, John. Have you ever wanted to use a component library like Storybook in your Drupal site without the limitations of Twig.js? There's a module for that. It's called Component Libraries Theme Server. It was created in January 2022 by one of today's guests, Natia Bosch, and it has 1.0.0 RC5 and 2.0.0 beta 3 versions available, the latter of which supports Drupal 9 and 10. It is actively maintained. In fact, the most recent commit was earlier this month. In terms of open issues, it has nine open issues, two of which are bugs against the 2.x branch, which is pretty good considering the module is in use by over 1,500 sites.



 The module works by allowing you to develop your components in your preferred component library and use them in Drupal. It is notionally agnostic of the component library solution, but the main integration really is with Storybook, including support for things like knobs, which are dynamic properties in your components, and other components' stories, which capture interesting states of a component to show and test the ways in which a component can be used. There is also a companion add-on for Storybook to make it aware of your Drupal site. Now, within Storybook, it allows you to preview components rendered through your Drupal themes, so the rendering is always consistent between Storybook and Drupal.



 It allows your Storybook components to use Drupal-style JavaScript, and there is also a companion module called SCCStoryGenerator that can automatically convert a Drupal single directory component, component.yaml, definition to a Storybook component, story format,



 stories.yaml file for a smoother integration. So let's talk about component libraries' themes are. I really just want to hear you say that last bullet one more time fast.



 I'm kidding. I'm kidding.



 So I guess my first question here, and it may or may not be a popular one, is this seems like it's pretty Drupal-twig-focused. Is that accurate? If I were using a decoupled frontend, would I be able to use this to link those, you know, my Drupal to my Storybook to my frontend as well?



 It is completely Drupal-focused. It's actually a point.



 What we've realized over the years is that we were trying to emulate what Drupal will do when rendering this particular component, and that's hard. It's admittedly very hard because we are writing PHP extensions and then we have to emulate them in JavaScript, and then you enable a contrib module, and you don't know that those extensions come in. So the solution that I proposed in that module is to just use Drupal. Drupal knows how to render Drupal. Right. Yeah, it makes a lot of sense. And clearly, it's very popular. 1,500 sites are using it, right?



 Has anybody on the call, well, other than   Mateu and maybe   Mike , has anybody else used this module or interacted with component libraries in this fight?



 Silence. Okay. Fair enough.



 And Storybook-specific  Mateu just working with Storybook, or is there a way or ability to extend it to some other component library service? It is theoretically agnostic to the component library that you use. Admittedly, I don't know of anyone that is using this module and not using Storybook. Right. I like Storybook a lot. I would even go further and say it's the best in their space.



 Makes sense. Makes sense. And I mean, I think I'm pretty sure it's widely used. I know there was another component library out there early on, which the name is escaping me, but it seems to have dwindled in popularity maybe or the support. Pattern Lab, maybe. Pattern Lab, that was it.



 I have not heard much about Pattern Lab lately. So, okay. Martin, any other fun facts or anything else about this module we should know?



 I mean, I think if anybody had more to share, it would probably be   Mateu But yeah, I'm definitely interested in it. I honestly haven't had much chance to play around with Storybook, but hopefully in the future when I get the chance, I'll definitely give this a try.



 I know that the Knobs piece of it is actually interesting because I know, so I'm on a project we use Storybook, and we have configuration within Storybook to give designers the ability to say, "Well, this is what it's going to look like if it's blue," or "This is what it's going to look like if you use the right versus the left." And that aspect of it is pretty cool, and to be able to integrate that into Drupal better would be awesome. So, definitely a good set of features there. I think I can understand why so many people are using this.



 One thing that I like as well is that it allows QA engineers to break your components very fast. They're really easy if they have to, and also it's a good tool to pair with visual regression for QA because you have Storybook that generates different renderings of your same component and you do visual regression on that.



 That's a great point, too. Yeah, you can jump in there, set a couple knobs, and then be like, "Hey, this thing doesn't work. Let's go back to the drawing board," right? So, I'm guessing that this module, you don't enable on production. It's completely development-only, correct? Yeah, for now it is.



 So, there is a valid use case that could be like, "I want to show my component library to the world." I don't know. The European government will do that, right? So, others can know what it looks like, but right now that is not supported because we are disabling a lot of the caching protections that Drupal uses so you can work comfortably in your local.



 I envision this being used to   Mike 's point, almost like on a statically generated front-end where you're building components on the back-end and you're using this integration, and then it's static and people are using it on the front-end, but yeah, that might be one use case of many, right?



 All right, well, as always, thanks, Martin, and let's move on to our primary topic,   Mike Herchel Actually, no.  Mateu I'm going to-- What? No? You want to-- No, no, no, no, no. I get it. That's cool. I don't want to talk about single directory components.



 I think John just chose me. [laughter] I said you had a chosen one. There you go. All right,  Mateu the big question, the million-dollar question, if you will, for this episode, what are single directory components? I defer that to   Mike .



 [laughter] John has not chosen me, so it's going to go back to you. All right.



 Well, single directory components is just a way of implementing components in Drupal. That's the simple answer, and probably not very nuanced, but components is a thing that's been out there in the web industry for a long time, and Drupal didn't have a formal way of implementing it



 from what I've got during all this journey. Everyone was doing it. So many people were doing this, and everyone was doing it in a slightly different way. Not very different because it is what it is.



 Components are a way to encapsulate semantic elements that then you put on your pages, right? And we have the template system, which is kind of the integral part of it. And then we know how to add JavaScript, CSS, and assets in Drupal. So kind of making that combination,



 the way that we do the combination is our proposal of single directory components.



 So it's like kind of taking a step back here, right? It's kind of like there are two ways to think of components, right? Or at least maybe for me, and this might be a gross simplification. You guys can correct me if I'm wrong here. But we used to think of components as like, hey, you're working with a design system. The design system has atomic design principles dictate like atoms, and then you get to like a component level, right, where it's more of like an interaction point or a group of atoms together, right? And then that kind of merge, or migrated, I guess I should say, from like the design world to the development world, right? And like, and it's been a while since I've themed a Drupal site, so bear with me here, folks. But Drupal theming to me always felt like, okay, you have your Twig template, you have your CSS and your JavaScript that support that Twig template. And then, you know, basically that CSS and JavaScript's usually all in like one massive file, and then your Twig template's in like some sort of you know, template directory, right? This feels like a better way to organize those things, right? Where you have your Twig template, your JavaScript, your CSS all in one, air quotes, directory folder, right, that says, hey, here's the component name, and here's all the stuff that supports that. Is that a fair way of describing this? Yeah, yeah, and it gives you some additional benefits too. So like, let's say that you have a component, your component has, you know, your Twig file, your CSS file, you know, a SAS file that will generate that CSS file, your JavaScript file in there.



 And in addition to like, it's all together. So let's say you want to take that component, and you just want to copy and paste that from one theme to another, it's just easy peasy lemon breezy. You just copy, you paste it, you make your modifications to your CSS so it can pull in the new SAS variables or CSS variables that you need, and it'll just straighten and it'll just straight up work. SDC will automatically generate a library, like kind of an auto-generated library for every single component and automatically load that whenever the component is generated. In addition to all of that, when you're creating an SDC, you have an option to create a schema for it. So the schema will like define like the data that the SDC is expecting, you know, so like if you're a CTA, you'll have like maybe a title, some text, you know, and then like a link and the link, the text link, you know, and you'd find that, you know, you say, I'm getting this data and it's a string, this data is a hyperlink, this data is, you know, a Boolean or something like that. And what's really useful is that, number one, that will tell, that tells the developer what the SDC is expecting.



 But on top of that, in the future, and honestly, like right now, because that data, because Drupal is aware of what data that SDC is expecting, you can auto-generate a form. You know, let's say you're like you're in a CK editor, you know, like there could be a module that you hit a button and you select an SDC and then you populate the SDC with the data and Drupal will know like what data it needs to collect and how to inject that into the SDC and stuff like that. And that's going to make like, number one, the development experience a lot easier because, you know, as I said, copying and pasting SDCs and being able to leave them when necessary without having to browse around. And then number two, like the site building experiences, like once contrib and core catches up to this, it's just going to dramatically accelerate that too. Yeah, so I think a lot about, you talk about the site building experience, right? I think a lot about Layout Builder with STCs, as you call them, which for those people that are keeping up, that's single directory components. That's an acronym, folks. Also, another acronym that   Mike  just used is CTA, which is Call to Action, just for anybody that's not familiar with those.



 Okay, so this seems to make a lot more sense, a lot more sense to me. Where did the idea of adding single directory components to Drupal come from?



 That's you, Matteo.



 Trying to see how far back we need to remind for that.



 For us,   Mike  and I used to work together a little bit.



 And we were at a project where we were using this kind of proto version or earlier version of single directory components. We were using Fractal, right?



 And then I had sometimes, sometimes, light on my hands, and then decided, well, it would be nice. If I could try to propose a way to standardize doing this, right? Starting from there, now the code that we are running in Drupal core nowadays barely resembles the initial version, but it started out as a client project implementation. Yeah, and so Matteo took that client project and he made the module. It's called CL components. At one point, I think Matteo, I don't know if we were on a video call or something like that and you were demoing it to me. And I'm like, dude, it'd be super cool if we could get this into Drupal core.



 Matteo, he's done a lot of core work. I have done a lot of core work. And he was like, yeah, we probably could. I talked to the product manager, Lori Escola, and I proposed it to him. He's like, yeah, yes, it seems like a cool idea.



 So we, and by we, I mean just Matteo,



 worked on it pretty much all the time. And he was busting his butt just doing this. And this was, Drupal 10.0 was out, and we were on a deadline, self-imposed deadline, to make Drupal core 10.1. And it was a little hairy at times. We had, like, there was a little drama here and there, like, as we're doing it, you know, like, we would, I would constantly be, like, he would do something and then record a video. I would blog about it. And like, from my point of view, I was trying to get, like, the Drupal community very, very excited about this with the express intention of putting pressure on the core committers and giving attention to hopefully get this into Drupal 10.1. You know, and so I would, like, you know, ping people on occasion if they haven't looked at it and be like, hey, gentle ping again, don't forget about this. You know, hey, I saw you left a review for this. Do you mind finishing that review? And a lot of things like this. And, you know, we ended up getting some, like, really quality reviews from people like Lee Rollins and Alex Pot. We ended up coming back and making those changes and getting subsequent reviews.



 And, you know, and then there was the point where, you know, it was around, like, April or something and we were trying to get this into 10.1. And so finally we got it into 10.1. But what we realized when we got it into Drupal 10.1 is it was going in as 10.1 alpha, which means it wasn't actually going to be like an actual release. It was just going to be in, like, the Git branch.



 And so we were like, oh, crap, what do we do now? And so, like, at that point, like, I'm messaging, like, Mattel, like, you know, behind the scenes. And I'm like, hell or high water, we're going to get this into the beta, you know, and so, like, message lowery and we're trying to, like, figure out the list of stuff that we need to do. And long story short, we just get this done. And, you know, we get the thumbs up on that from catch. And it got marked as beta just, like, right under the 10.1 deadline. And so that was super exciting, a little bit stressful, but honestly fun.



 We had a couple hours to spare. Yeah, yeah, yeah.



 Yeah, I want to fill in some of the details that   Mike  left out. And he always says, did all the work. And I think this was a very successful partnership. Like, this wouldn't be in Drupal core without   Mike 's involvement, whatever he says and he tells to anyone. Because our agreement was,   Mike , I'll do this when he told me this should be in Drupal core. I'll do this if you deal with all the red tape, with all of the wrangling people around. I write a code. You do your social stuff to make people do the things that need to happen for this to go into core. And this is something that probably is valuable for anyone wanting to put something into core. It's not enough to do the code. You need a mic.



 Yeah, yeah. You need to get on the radar of the core committers. You need to say, this is valuable.



 There was one issue we had to open up, and they basically said, you have to do your due diligence. Is this the type of implementation of components that we want? What do other systems do? Do you want to do single file components? Do we want to do single directory components? Do we want to do something else? We had to justify pretty much every single architectural decision that we made.



 A lot of stuff like that. But a lot of this is just finding out what is the next step.



 If it's just sitting there, we need to know what the next step is. And even if that next step is us doing extra work, well, then, hey, then we're making progress.



 Yeah, and luckily the process doesn't allow for anyone, especially me coming here and saying, trust me, this is what we're doing. And this is how everyone will do Drupal front-end development in the future. There are structures and decision-making processes, and those need to be followed by very busy people.



 Yeah.



 So that's a really great description of how core development work gets accomplished. So thank you guys both for working on that. So where does support stand for this in Drupal core? Do you still need a contrib module in order to use it?



 So obviously we don't need a contrib module, right, because it's in Drupal core. But right now it's experimental. So what that means is it's a separate module in Drupal core that you have to go into the extend navigation, and then you have to check it, and it gives you a warning to say, hey, this is experimental. Don't do this in production, even though it's frickin' awesome. Of course, right?



 And I'm using that in production.



 But that being said, heads up on this that once we stabilize this, it is not going to be a separate module. So this is going to--like, right now it's a separate module because it is experimental. But once this stabilizes, it's just going to be part of the general theme system. It will always be turned on, and there's nothing you got to do except for just start using that. Yeah, and I could spell out the issue number for the roadmap to stability. Probably not very useful. Probably we can add that to the notes. But we have an issue. Like, if you're a sewing client and you want to contribute, I think we have a bunch of work ahead of us. We are thinking that long beta is best for this type of work, and we're just gathering input right now. And well, we're gathering input and making progress at the same time, both things. We've closed a lot of documentation issues, but you never have enough good documentation. So go there and contribute if that's something that you want to see happening sooner rather than later. And   Mateu you mentioned long beta, so what are you thinking, like 10.3 or something like that to get it in?



 Yeah, I mean-- You want to still try to shoot for 10.2. I know at one point we were talking about 10.2, and people were pushing back against that. I think that skipping at least one cycle would be best.



 And there are many people running this in production. This is more stable than many contribute modules that we run in production.



 But still, it's marked as experimental because Core has very high standards, understandably.



 And there are a few bugs here and there. Is the decision to move it to Core driven by the number of bugs there are, or is it more of you guys feeling like it's ready? It's more the latter and the recommendation of Kat, Nathaniel.



 He's like, when we were marking this as beta, he was thinking, yeah, let's do this as beta because there is not much of an API change risk here.



 But let's run it for a longer time than usual so we can get to all the ins and outs. Because like   Mike  mentioned, once it's made stable, you won't be able to disable it, just like you cannot disable the render pipeline.



 That was going to be my question, was like, it's experimental now. Obviously, you can turn it on, you can turn it off. But once it goes into Drupal Core, it's just going to be there. That's going to be the way Drupal theming works. It's not going to be something that you can be like, oh, no, I want to go back to the old way. So it's going to be something that people are going to have to probably upgrade to. Yes, no. I would say no. Everything is going to continue to work. So the way that you invoke a single directory component is just by basically doing either a twig include or a twig embed from your normal template file. So let's say you'll have your node dash dash teaser dash dash html.twig, and you want to load a teaser component. Normally, you would have maybe your markup in that node dash dash teaser.html.twig. But instead of doing that, you would say like you would do a twig embed, which is like a normal twig tag. And you would point that to the SDC that you want to load. And then the SDC would then like load any JavaScript, CSS, yada, yada, yada.



 You can also invoke SDCs through--



 Oh, geez. Was it there?



 I'm thinking not there. Render--



 Renderable. Yeah, yeah, yeah. Thank you. Renderable. Yep, yep. So you can do it that way too. But I like doing it like in a template because I'm more familiar with Twig and I'm more of a front ender. Does that make sense? Yeah, I won't break your current theme.



 It'll just be in addition to you have the ability to kind of like enable it in your Twig templates. Yeah. And start using that directory structure and that structure of components. Absolutely, absolutely. Yeah, yeah, yep, yep. So nothing's going to break. Nothing's going to break.



 Is it possible to bypass the current templates? Like if you did a theme registry alter or something, could you take out the field templates and use only your components? Or do they have to be called from a template or renderable to start?



 Oh, no.



 Yeah, that's the kind of stuff that makes my mind spin and makes me want to write another question.



 Yeah, right now you start from a template, right? That's what we got in score because you got to limit scope if you're going to get anything done. So, yes, you get it in there. You can add it as a renderable array as well, but that's just one level up or down depending how you look at it.



 But, yeah, ideally in the future you will have different ways to add it.



 Let's say you could add some extra metadata that says whenever you see a field of this type, you use this component, right? This kind of stuff is still in the flux.



 Some of it has already started and some of it just will happen maybe in the future. A lot of what we are hoping to accomplish, UI patterns, the UI suite of modules has already done from their perspective.



 I'm going to try to channel my best Nick here because as our listeners know, Nick is a huge component, a huge component, a huge proponent of web components.



   Mike Herchel I'm pointing this one at you. Can you explain to us how single directory components are different from web components? I like how a web component can run. Yeah, it can be used on a t-shirt. Maybe you can make t-shirts.



 So, long story short, they're totally different. Web components, in my opinion, are horribly named. Web components is a suite of technology.



 It's a group of technologies that allow you to do things like custom elements, encapsulation, HTML, or like templates, Shadow DOM and stuff like that. It allows you to basically group a component into a JavaScript file, load some CSS, and there's libraries like Lit that help you do this. Web components are a technology that's supported by all browsers and this. But the fact that a component on the web is not a web component, which is so dumb. Web components were just named horribly.



 A component on the web is something like a card component or a call to action component, a CTA component, or a button component. And then components can be nested. So, a header component, a footer component, all these things are components and then most of them are reusable. I want to reuse this card component and just swap out the data here and there and just use it in all different places.



 So, single directory components is Drupal's implementation of the ladder right there. So, we want to enable regular components, easy to use, within Drupal. And we want to have a standardized way of doing that so the community can build off of that, you know, through things like contrib and all that, you know. So, fair to say single directory components are more of the web implementation of design components and web components are really like a grouping of technology in your browser. Yeah, a specific technology, yeah. Now, there is nothing stopping you from using web components within your single directory components. So, you can use all types of like modern JavaScript, including React, web components, you know, Vue, Angular, anything like that in your regular single directory components. But it's just like the whole idea of calling a web component that is just dumb, you know. Do you envision contrib space to include these components that you could install like you would with a module? Let's say they could be components of headers and cards. Yeah, I think that would be great. Like, other technology stacks have like shared component libraries. And there's no reason why Drupal can't do this, you know. Like, the technology, like, SDC needs to stabilize, of course, and people need to figure out how they use that.



 And like, think about integrations with like recipes. I don't know if you're familiar with like what recipes is. It's basically a way to bring down a single grouping of functionality. What if recipes can include an SDC, you know. And at that point, like, the amount of work to style it would just be, would be minimal, you know.



 Yeah, and modules as well.



 Let's think of a module. Oh, the media library, right? That's something that everyone is familiar with. We could use single directory components inside of the module. And then we could have like displaying the card for the media chooser, right?



 And then each theme, let's say Claro, could take that component and replace it because Claro needs to do some special stuff in a way that it shows that particular card. So we can have modules and themes work together and override one another. And as a programming note, Jim Burch will be joining us next week to talk about the recipes initiative. So we will definitely, definitely get into that. I think it's super interesting that, you know, you just mentioned that,   Mike  and Matteo, because like the way I'm thinking about this in my head is like, you know, everybody's working with the design system. Design systems always have, are componentized basically.



 And then like a lot of people are moving those components into like layout builder blocks. And I see this as being like a very useful way to organize that information and that theme and to be able to, you know, to be able to, you know, get all of the benefits from this using kind of some already pre-existing structures. So I think that's super interesting. Does SPC make Drupal theming any easier? If so, how? Yeah, like the easiest thing is if you have SCCs that you've already done, like, I mean, I'm using single directory components at my job and there's been, I haven't been on my job for more than a couple months, but there's already cases where I've just copied and pasted one into another, made modifications and saved me a week or weeks worth of work. Like, that's the biggest deal now. Granted, I could have done the same thing.



 But I would have had to copy, I would have had to copy, you know, the template file, rename the template file, copy the CSS file, rename that, I would have copy the, create the library definition and all this type of stuff. And that fact right there makes it just a lot easier. And like something else, as a developer, we all know that CSS is really scary to delete sometimes. The nature of CSS is very global. And sometimes you don't know when that CSS is being loaded, where it's being loaded, when all it's affecting. Because of the nature of like an SDC being so componentized, you can be very confident that the CSS is only being loaded when the SDC is being there. And as long as you have the CSS go properly, then it's fine. So it's very easy to like, there's some quote somewhere that says like, well, organized codes, it's easy to delete.



 And this is it. I believe that. I'm also sorry, as you were talking, I just had the great realization that it's going to make editing CSS a lot easier because the last time again, haven't edited or built a theme in quite a while. But the last time I did it, aggregation was turned on. And I was looking at something and I'm like, oh, here's the style I need to update. And I had to go shut aggregation off and figure out what file it was in, figure out where it was. Like, if you know what component you're editing, like you can just go to that CSS file and find the, you know, the property, right? Makes it a little, makes it a little bit easier for that theme to go. I don't know. I'm going to play devil's advocate here. Go for it. I feel like,   Mike , when you copied all those components, didn't you also have to copy all the template files that were calling the components? I mean, I copied, like, the embed file, like the embed and just did that. But that was honestly kind of straightforward.



 As long as the, like, it seems like you still are going to have to do that painful process of, like, finding the right template file in Drupal with its naming convention or whatever. And then the components, I feel like there's going to be a huge benefit in sharing the same markup across multiple template files that we don't have now in Drupal. We just write it over and over again, which is a big pain in the head. But it still seems like you can't really skip the Drupal piece yet, which is why I was trying to get to the, like, can you override it in the theme registry? Because I feel like if we could skip that, that would be a big time saver. But the CSS thing also makes me a little nervous, and this is probably just because I've seen a lot of bad CSS. But it seems like it would be really easy to, like, not get your scope right because you don't know that, like, this button is going to be on eight pages. And then the style for that button overrides other buttons. Like, it just, it's, this is one of these things where if you are the architect of the CSS, you know exactly how it works and it's going to be fine. But when you hand that off to the next person, it's going to be really hard for that person who isn't going to know what component they're editing. They still have to go through that process of figuring out where that CSS file or where the component CSS is located. So I don't know. It seems like it's going to be very useful, especially for very big projects where you do have things like cards that are, you know, it's the same markup, but maybe, you know, different. Configurations in different places use for different fields. Is it a block? Is it a paragraph? Like, there's a bunch of stuff where you're going to get a huge consolidation of stuff. But it is also like another level of complexity that we're adding. So I'm happy that it's backwards compatible in the way that, like, people kind of ease into it and figure out, like, you know, save them the most time and use it or it makes no sense. One way of seeing it, I think, is like, it's like when you refactor your code. You have, like, lines of code that are exactly or almost exactly the same in seven or eight different places. And you then refactor that into a function. And then, of course, you have to call that function from the original place. Right. So the embed process is the calling that function from the original place. And the benefit of this refactor is that when you fix something, you fix it everywhere in your site. When you like that thing that I think that that part does make it easier.



 It is a very good point to the CSS coping. Right. SDC comes with an opinionated and totally optional way of scoping your CSS. It will give you some standardized structure that you can target in your components CSS to make sure that you are scoping it right. Right. Of course, you can go off to race and you can create those complex interactions between components that is very hard to detect, especially when you have like editors putting components in a page and it fixed itself or it started breaking again. Right. But it is something that was thought about. And there is a recommendation of a potential solution. However, I've learned with this process that frontend developers are very particular on their markup. You don't touch their markup. I don't believe that at all. Any frontend developer I've ever worked with has not had an opinion, so to speak of. Sorry, continue.



 And well.



 And it's completely legitimate. What do I know about markup? Right. I know about this problem and I know about a potential solution to fix it, but I doesn't make sense to enforce it. It is in the docs how to maybe address that. But if CSS is horrible, like, yeah. Yeah. I mean, you can't really fix bad CSS. Right. Like, bad CSS is going to be bad CSS. But I wonder, I guess, like, this clearly is a solution that you can't just drop in. Like, you have to put some thought behind and you kind of have to structure your project in the way of like, hey, we're going to use single directory components. And here's some documentation so that you understand what we're trying to achieve here on the project. Right.



 And then you can do some things where you're just going to like drop it in there and like everybody's going to use it like it like the project code and the project structure has to kind of support that it sounds like. Yeah, I think my my big concern comes from my personal experience of working with the agencies that deliver Drupal websites is pretty clear after the fact that they didn't really know what they were doing.



 And so we have to take on maintain those. And so that's how I end up seeing a lot of bad stuff as you see what people do in their themes. And you're like, oh, my goodness. And now we're giving them another really cool tool that they're not going to go use. And so I'm like, oh, man, what am I going to have to maintain with this? But I do see like from our perspective of now taking that over how that could be really beneficial because we would be able to fix it much faster. And I'll just. Yeah.



 And the hope for that is like now there's like one standard way of making components like Jenna. I'm sure you've seen like I have created components by two or three different ways over the years, you know, and you have to figure out how that's going. Now there's going to be one standard way of doing it. And this is going to be this is going to be the best practice right here going forward. So like sure, they don't have to use a sure they can continue to try to run their own components system. But the hope is that through like podcasts like this, they will learn about SDC and they will start using it.



 All five of our listeners again will know all about SDC. I'm kidding. We have more than five listeners. You're going to get like you're going to at least get eight listeners for this. Yeah. Yeah.



 Just because of you, we're going to give that three listener bump,   Mike . I was more thinking  Mateu but yeah. Yeah, you're probably right. Anyway. Yeah.



 So I mean, I think, I think, you know, Jen, like I totally hear you actually just came off of a call with a client where we were talking about somebody implementing something in not necessarily the best way.



 But I almost like I don't know, maybe I'm in turn, you know, eternally optimistic where I'm like, yes, this will allow people to like do things better. Right. But the other thing that I realized in having this conversation be fine folks is that like, you know, it lends itself to a better organizational, like enterprise level solution. Right. Because I think a lot of a lot of enterprises, again, as I said, previously moving towards like design systems and like this type of thinking and structure is really like, you know, is really appealing. Right. For a number of reasons. And I think we're highlighting a lot of them. So I think like that's that's going to help kind of push this push this forward and get people on board with like, hey, let's do it this way because it's gonna, you know, it's gonna make make things better for everybody. Again, I could just be being idealistic. Yep, I can see that I can also see like, just there's a lot of value in the ability to organize things however you want. I feel like having a long beta is also really good for this because there's a bunch of stuff we can't imagine people doing with it. And through having that data process, we'll start to see what people are doing that, you know, be able to help make that process a little easier for everyone. A little more standard. So yeah, I'm excited about using myself now. So, thanks.



   Mike  earlier you talked about schema or the STC's. I don't know if either of you want to elaborate on why that's optional what it is and why it's beneficial. I love it to take that one.



 I think that's also another way of simplifying the implications of being frontend developer. So let me elaborate on that. It is adding some complexity from the implementation side.



 So what schemas are is that you take the time to think about what is my component doing? What are the inputs? What's the data my feeding to this card? Right. Probably has a title, probably maybe has a link in there. And it also has an area where you can add whatever HTML you need to have go into that card. Right. That would be a valid way of describing a card. So you take that reasoning about your component and you put it in a way that the system can understand it. You describe that the title is a string that it has. You can add the max length. You can even enforce a certain format. And we do that in a language called JSON schema because it's like super standard. It's everywhere. And many developers will be familiar with it. But maybe not everyone. So we take that and then we define the API of a frontend piece. Right. And that for me is huge because prior to this, every single element class, anything in that markup was an API. So if anyone was building a top on top of something that you were doing, you changed a div and made it an article. You might have been breaking their styles. Right. Right now you're writing the API of that in a semantic way. So you can have a better time maintaining shared components. Either you share them across projects. Either you share them with the community, like Stephen was suggesting earlier. That's what the schema is useful for the first part of it. The other part is that once you describe it, you have like the heading being a string. You can go further and say, if I was to write a form for an editor to put a component in the page, right? Imagine a module that creates forms for components so editors can place them in the page. Right. We can have those forms be auto generated without any effort. Right. Text field for the heading.



 With a week for that blob of HTML. For those of you that are not watching the video, Jen and I's heads both just exploded. Based on the auto generation of edit forms. Continue   Mateu sorry. Yeah. And there is a there is a contrib or SDC display that will do just that. It will let you create those forms, for instance, and map them to fields and stuff like that.



 I think that's an area where it has a lot of potential. Like you could have your front end developers create components so they can map them in the in the templates. Like we said before, we call them like as the function that we refactored, but also those same components build up your repository of components in the site. And with the help of country modules, you can have side builder go into layout builder and you can have all these components are make I are creating blocks without any other efforts than juggling on a module. You can have components be blocks and then you drag them with layout builder into your page. So those kind of integrations. Are the end goal here, right? Just turns your front end developers in the back end developers in a language. They're already familiar with working in. That's that's awesome.



 I want to add to all this that schemas when you're creating a when you are creating a theme schemas are optional. You need to have the component YAML file there, but the actual schema does not need to be generated. So if you're not going to be sharing your components, you're not going to be auto generating something. You just want to group it and have the developer a better developer experience with that cream schema. You are able to do that. Now, if you're if you have your SDC and a module schemas are mandatory.



 And in addition to that, if you ever want to if you want to override an SDC, the the original SDC has to have a scheme on the new one has to have the schema to make sure they match. OK, so so so those are a couple of things to you know. Yeah, yeah, let's dig into that one a little bit because I think  Mateu talked about this a little bit earlier. You just talked about it now and that's kind of overriding the SDCs, right?



 So I'm going to kind of tie the two things that each of you said together and then I'll ask my question, right? So  Mateu was talking about modules or themes being able to override SDCs.   Mike  just said that in order to override an SDC, it has to have a schema, right? So like it is possible to override SDCs, right? But I guess like what what are the what are the the use cases or what are the thinking on the use cases for that? And what I mean by that is obviously like a module can define an SDC, right? So like if we were to talk about I don't know, let's do like a newsletter sign up module, right? Say the MailChimp module wanted to create an SDC for a newsletter signing, right? But like for some reason I needed to add fields to that or I needed to enhance that component, right? My theme could override that, right?



 How would I go about I guess doing that, right? So well, first thing is that the module needs to have a needs to have a schema, right? And then I just call that into my theme and then start editing it or is there something else there that I may maybe miss?



 Yeah, and that also highlights the importance of schemas, right? Because you want to make sure that if you are overriding some other modules component that you're doing it right, that both components take in the same inputs, right? Going back again to the refactored function analogy, they always take the same variables, the same arguments, right? If the original changes the list of arguments, the one that you're calling with in or overriding, then it's passing the wrong data, right? So that's why when you're doing these overrides, everyone involved should have the schema defined and there is a layer inside of SDC that will assess compatibility between the two. Let's define what we mean by override. Are we also saying replace? Actually, that's even a better way of describing it because it is replacing it. What you do is, let's say that the signup component that you take from Contrib doesn't really work because you need some special markup for some wrapper to add some special CSS because that's what you need to do on your site, right? What you do is you go into the Let's see a module or whatever the hypothetical module is, you copy it, like literally take a copy the directory from there and you paste it in your theme. And then just by doing that, you're using the component in your theme because that takes precedence, right? So then you start tweaking it and even when it's the same module calling the component, instead of calling the one that it provides, it will take Drupal with load. No, no, no, no. Use the other word. That's based on, hold on, one clarifying question there. That's based on the directory name or the YAML file inside that component?



 So  Mateu there's the replaces key that you have to define within the replacement. So it's like you have to copy and paste the single directory, the SDC from the module into your theme, but then you have to edit the schema and say this replaces and then the syntax is, you know, module name colon, you know, that whatever. Whatever component that is. Yeah. And using the awesome docs that may need some help that we have. So is there a case where we're going down the theming rabbit hole a bit here, but that's kind of what we do sometimes. So is there a case here where you can enhance a single directory component instead of replacing it? So take the first example, the example we just used, right? I need to redefine a schema. I'm going to do a replace, right? But say, hey, like a new example, I want to update a single directory component, right? So the hypothetical email signup component does everything I want it to do. I just need to add two fields to it, phone number field and, you know, nickname field, right?



 Do I have to still copy the component and overwrite it, replace it, or can I append in some method?



 You have to copy and paste the whole thing. And that was an intentional architectural decision because we could do like we, by we, I'm at  Mateu could have written something like, hey, I want to be able to load another CSS file or I want to be able to load these extra schema stuff. But the problem that presents is that like someone down the road, let's call this person, Jen, is inheriting your screwed up site.



 They will have to figure out what's going on and that'll make things like really, really complicated at that point. You know, the benefit of having everything in one component is that you know where your data is coming from. You know where your markup is coming from and your CSS is coming from. Right. So it's similar to like, you know, how Drupal works now where you want to overwrite a template file, you just move it into your theme and do it, right? Yeah. So that makes a lot of sense. Okay. So that makes a lot of sense.



 I'm also realizing here that  Mateu is the muscle and   Mike  is really just the hype man, maybe, for this initiative. I like that. I like that. But, you know, I'm just going to let the listeners figure that out. I mean, I do like a lot of testing and, you know, throw out ideas on occasion, but I like the idea of hype man. That's great. So you mentioned the SL server module and you mentioned a module that automatically generates blocks from components. Are there any other useful contrib modules that enhance STCs?



 I'd say that a CL server and some of the modules that enhance STC start with CL because STC is kind of the core adaptation of CL components. So those modules already existed and there is a branch version to branch that is compatible with STC. So CL develop will kind of add some nice tees on development experience, like it will generate a list of all available components. It will also highlight what you're using one component or another will describe graphically the schema that we talked about. It will tell you if someone took the time to say this is a card and it has a heading. Well, it will spell it out for you. Has a heading. So that kind of stuff. And as they see display will will let you use or sorry, map components into field formatters with the graphical UI. So if you want to use my marquee component for your headings, you can have your text scroll across the screen and then there will be one that will be STC with the week. Something like that that will let you have a button where and have a pop up like add my component here inside of the week. That one doesn't exist yet, but it will. There's also a we have a documentation page for this, which I just realized that your STC display is not on and not on this. But so if you go to the single directory components documentation, which is like under Drupal theming section, we have like modules that extend single directory components and listed in there is also there's a module called STC style guide, which is how put a list of your STC. You can kind of look at them. There's.



 There's CL editorial, which is another  Mateu module. And this is really cool. It's almost like a helper module for other modules. So like correct me if I'm wrong,  Mateu Like, but like, let's say you have any type of UI now or in the future that you're going to select a list of single directory components from. You want that UI to look good. You want to like maybe a little grid with some check boxes and little icons and all that other good stuff. And you want that to be standardized and accessible. That that module will give you that so you don't have to implement it yourself and save save all that time. So there's there's a lot of stuff like this that's been going on. That's the editorial. I can see that being some core functionality sometime in the future.



 And there's also a generator, which is a address command to generate a component. And I think, you actually did you don't have an outstanding request for where it can like where address can create STC. Actually, Drush will be able to generate or scaffold an STC for you without anything else installed. It's part of Drush 12 core now. Yeah. So there's lots and lots of like lots of momentum in the in the contrib space around this type of stuff, which is like super exciting because I think that's like, you know, like realize the real power of single directory components. And I have a lot of ideas in my head, you know, around layout builder and things like the WYSIWYG and Gutenberg and stuff like that. So like there's tons of stuff to do. And it's all really exciting. Do single directory components help out with headless at all? No. No.



 No, but we were talking about the web components earlier and they have to merit of making   Mike  dislike their name. But you can also use them inside of single directory components all the same. You won't help your effort of decoupling, but there is nothing stopping you from saying my single directory component is a react component that I render or a web component that I render. And then I pass data into that because we know how to pass data into single directory components. So in a way, we are streamlining or standardizing the integration of the concept of components into Drupal.



 And I think my opinion is a great way to plug your decoupled components if you already have them into Drupal. That was kind of like my thought as we were having this conversation and why I wanted to ask or haveStephen ask this question.



 Because like it feels to me like obviously it's not going to be like an assist on the front end, right? And if you're not using Twig templates in your decoupled, you know, or headless architecture, like then that's not going to help all that much. But I feel from like an organizational and a data or data integrity standpoint to your front end, this could be super helpful. Yeah, and I could see like from progressive decoupling, you know, where you have a component that like loads data from like an external source or something like that. That's very, like STC would be very helpful for something like that. Man,   Mike , I feel like this could be your next blog post.



 Oh, man. I got it. I'm behind on my blog post. All right. Well, maybe we'll see it. We'll see it in a couple of months then. Everyone should subscribe to   Mike 's blog. I really like it. We will. You know what we'll do? We'll put a whole list of links in the resources section to the modules that we talked about. Also,   Mike , drop a link to your blog down there and any of your favorite single directory component blog posts. We'll send those out when we send the show out as well so that way our listeners can read through on that stuff.



 Okay. As we bring this show in for a landing here,  Mateu you already talked about folks getting into the issue queue and helping out.



 Any other ways folks can get involved, help contribute to the single directory components efforts in Drupal core?



 We'll take any volunteer labor for single directory components. This is just us. I take my sponsor time that Lullabot gives me 10 hours a week, more or less, and put it mostly into this. But that falls short. If you really want to see this happening, more people will need to step up.



 One very easy way to do it is to try it out and we have an issue with, I think it's four questions that can be answered in less than a minute and say things about single directory components. That is feedback that we'll take to release managers, etc., and say, "See, we cannot get this in. We need to change stuff." Or, "Everything works. Let's get it in." That's one thing. But to know about that, you need to go into the components channel in Slack.



 Join chat, maybe ask questions. If you say, "I want to contribute and I don't know how," someone will suggest something. It depends on your skill set, how you're versed in contributing to Drupal core. If you want to write a contrib, one of those cool contribs that need to happen, that's another way to contribute.



 You were reading my mind because I was like, "Oh, is there a Slack channel for this?" There it is. Jump into the components Slack. I'm assuming that's on Drupal Slack, right?



 On top of what  Mateu talked about, help spread the word about single directory components. The more people that use it, the better. The more people that create and share components.



 If you're going through the process of either creating your first single directory component or converting a component to single directory components, write a blog about it.



 Throw that up there. If you're going to a Drupal camp, give a talk about single directory components. You can reach out to  Mateu and we'll happily share some slides with you and stuff like this. Give some presentations on it. People need to know about this. It's very easy for us who are deeply involved in the Drupal community to know about it, but so many developers are just there working. They don't know that this necessarily exists anymore.



 Something else that helps out is if you do something really dumb and single directory components crashes, but it doesn't give a helpful error message, create an issue for that too. One thing that  Mateu has really done that I really like about single directory components is the error messages are super helpful. They tell you where exactly you're screwing up.



 There have been times where the error messages are just not helpful because  Mateu despite his infinite wisdom, hasn't foreseen people screwing up like I can screw up. Once you track down what you did wrong, say, "Hey, I wrote a component like this. It threw me for a loop. It took me two hours to track down what I did wrong."



 Things like that are things that will help people in the future. That's what makes   Mike  the best tester in the world because nobody can screw up like he can screw up. That's very true.



 I'll say that in general.



 We know that everyone's very busy and people are gifting us their time and we'll take the hose off feedback in Slack and we'll slowly sift through it. That's our preferred way of getting it. You don't have to follow structure, know anything prior. Just go in there and get your feedback. Ask your questions. Say whatever you need to say there.



 Some people will create issues. Some people will work on those issues. We have that going on. A lot of people are doing that kind of stuff. If you just want to take that minute to give us the feedback, that could be the next stable blocker that we need to fix.



 Just drop a line in Slack.



   Mike  and Matteo, thank you for joining us. This conversation has been great. I look forward to hearing more about and playing with single directory components in the future. Cool. Thanks for having us. Yeah. It was fun. If you have questions or feedback, reach out to us on x at Talking Drupal or you could reach us via email at show at TalkingDrupal.com. The best place to connect with us is on Drupal Slack on the Talking Drupal channel. Everybody's in Slack. It's the best way to connect with everybody.



 You, yes, you, just like Ned Camp did today, can promote your community event on Talking Drupal. Learn more at TalkingDrupal.com slash TD promo. Did you know there's a Talking Drupal newsletter? It contains more information about guest hosts, show notes, upcoming Drupal camps, local meetups and much more. Sign up for the newsletter at TalkingDrupal.com slash newsletter. And thank you, patrons, for supporting Talking Drupal. Your support is greatly appreciated. You can learn more about becoming a patron at TalkingDrupal.com and choosing the Become a Patron button.



 All right, everyone, you're almost out of here, I promise. The last part of the show here is the Shameless self-promotion part of the show. Some may say the most important.  Mateu if folks wanted to get a hold of you, what is the best way for them to do that?



 Slack, as much as I would like, an open source alternative to that. I think Slack is where everyone is. The components channel, or you can DM me. I will probably politely ask you to repeat that question in the components channel.



 But yeah, that's a good way. And you can also find me in the fabulous Drupal.community Mastodon instance. If you don't have a handle there and you do Drupal, it's free.



 Yeah, get on Mastodon, folks. It's the way of the future.



   Mike Herchel you once were on the DA board. You filled an at-large seat. Could you tell us a little bit before you tell us how to get a hold of you about the DA elections that are happening right now?



 Yeah, I'm actually technically still on it, too. My last meetings are going to be at the DrupalCon LIL, which I will be presenting on single directory components there, too.



 As of today, we're recording on Tuesday, September 23rd. Elections for the at-large Drupal Association board of directors seats are open.



 And so the board of directors has like 12, 13-something people on there. Two of those are elected by the community.



 And the terms are two years long, and they kind of overlap every year. So every year there's an election.



 And so we can include a link in the show notes on where to go. You have to be a member of the Drupal Association to vote.



 If you're not a member of the Drupal Association, you can join. But at this point, if you join right now, you probably still won't be able to vote because we don't want people just to join a whole bunch of fake accounts and then vote and do stuff like that.



 But it's important. There's a lot of really interesting decisions and kind of direction that me or the next person has input on when the DA meets and we get to decide what are the Drupal Association's priorities. Right now we're very focused much on innovation and, of course, marketing.



 And all that needs to be done for Drupal. And so I want the next person to really, really hopefully go hard on both of those topics. And if you are a Drupal Association member, you probably got an email. So this is just a friendly reminder to check your inbox for that voting link that   Mike  was talking about.   Mike , if folks wanted to get a hold of you, how could they best do that? Yeah, so my website is Herschel.com. That's H-E-R-C-H-E-L.com. My email address is   Mike  atHerchel I'm on Macedon at Macedon.social.mHerchel That's just because I don't really like  Mateu that much. I'm still on Twitter or X or whatever the heck it's called now, even though it's getting more toxic by the day.



 And yeah.



 And then, of course, I'm MHerchel in Drupal Slack and anyone can bother me there.



 Good deal. Jen, thanks for joining us. We look forward to having you for the next four weeks. How can folks get a hold of you if they want to chat?



 Best way is probably on Zillip, which is the open source alternative to Slack. The back-top community says I'm also on Drupal Slack. I'm also on Macedon. I'm on knock.social.



 And my username is JenLudin. Everywhere.



 Cool. I hear that backdrop is having an event in the next couple of weeks. Yes, it's not this week, but next week. It's an entirely online event.



 Runs 24 hours a day for people in every 10 zone. Three hours on three hours off, so you don't have to go straight for 24 hours.



 And yeah, there's an event this week too.



 Tonsidy's Drupal Camp is happening if you're in the Minneapolis area.



 Cool. We'll put links in the show notes for both of those events.



 Stephen Cross, as always, it's a pleasure to have you back, filling in. How can folks get a hold of you if they want to chat? Stephen Cross with a pH on X Twitter. I'm with JohnPicozzi I'm going to have to take a couple of breaths after that one. You folks can find me on all the major social networks, and Drupal.org at JohnPicozzi And you can find out more about E-PAN at epam.com. Stephen, you're up.



 And if you enjoy listening, we enjoy talking.



 Have a good one, everyone.