Directing How Single Directory Components Directly Simplify Theming

00:00
February 20th, 2025. It's the Lullabot Podcast.

00:19
Lullabot podcast episode 272. I'm Matt Kleve, Senior Developer at Lullabot with me, front end developer, Morgan Eck. Hi, Morgan. Hey, Matt, how's it going? Oh, I'm doing great. And I'm glad that we're back together again. We kind of took a little bit of a hiatus, didn't we? It's good to be back. It is. Sometimes life gets in the way and stuff happens and stuff gets put to the back burner. And yeah, we need to do this again. And it's our plan to do more. But I waited until February.

00:49
I saw January, 2025 come across my calendar and everybody does these like, you know, new year's resolutions and stuff. I wait until a month later just to make sure I really want to do it because new year's resolutions are always bound to fail. Right? Yeah. Smart. Give it a lead. So today we're talking a little bit about single directory components in Drupal. Very exciting stuff. And we have a few Lullabot developers that know all about it with us today.

01:19
Yeah, we've got a great group of Lullabot developers with us today, starting with Mateo Aguilo-Bach. Sorry if I pronounced that wrong. And he is, I'm not going to say this. I'm not going to pronounce it. I'm just going to spell it out. He is E-Zero-I-P-S-O on Drupal.org. And he's a lead engineer here at Lullabot. He's been here for 11 years, almost 12 years, which is crazy. He's in Mallorca in Spain.

01:47
and he's been doing Drupal for over 10 years, probably far more than that. I'm probably underselling that. And in that time, he's contributed over 3,000 commits, created an insane amount of modules, including the one that we're talking about today and many of its companion modules, and he serves as a core co-maintainer. He's worked on all kinds of projects here at Lullabot, including MSNBC, NBC, and IBM. Hey, Mateo. Hi, everyone.

02:16
Glad you're here. Glad to be here. Also with us today we have Bronze Hedwig from Drupal.org. He's a senior friend and developer from New York. New York, the city so nice they named it twice. He's been at Lullabot for two years, been developing Drupal websites since 2010, started his career in mobile and web game development, but quickly transitioned into building complex Drupal sites for large organizations. In his spare time.

02:41
He performs improv comedy, writes all sorts of things and runs a podcast network. So we've got an expert on the podcast today. Chris DeLuca. Hi, Chris. Hello, everybody. Glad to be here. The pressure's on now that you've said the podcast word. I can't screw up. Got to make us look good. That's right. All right. And we also have Javier Reartes with us today. He is Javi-air on Drupal.org and he's a senior front end developer here at Lullabot. Been here for three years.

03:09
He's coming at us from Argentina. I'm not even gonna say where, I can't even bother. He's been in Drupal since 2007 and has done both backend and front-end development in that time. And he became interested in computer programming at the age of 11, which is crazy, when he found a basic language manual. He's created numerous modules in the Drupal space and has contributed to many more. Hey Javier, it's nice to have you here. Hi, thank you.

03:37
Glad to be here, my first time on a podcast. Woo, welcome. I think BASIC was probably my first programming language, but I just copied it out of magazines. Back when you had to read the magazine and type it, those were the fun days. Yeah, I remember doing these fractals that went on this manual and I was, wow, this is nice. That's cool.

04:01
Also with us today, we have a senior friend and developer from Baltimore, Maryland, who's been at Lullabot for about three years. She creates sites that are accessible, intuitive, and maintainable, has helped build the e-commerce platform for the American Booksellers Association, contributed to a number of modules in the Drupal space. Pauline Judge, hi Pauline, glad you're here. Hi, it's good to be here. So today we're talking, we're diving into single directory components in Drupal 10.

04:31
what they are, why they matter, how they're changing Drupal theming. Mateo, the SDC module, I guess, was added to Core in Drupal 10.3, which was June of 24. It was experimental in Core before that. Just give a brief explanation of what it is to folks who might be unfamiliar with the concept, please. The idea behind this is just to solidify the common practice of, like, probably...

05:00
most agencies have been adopting into bringing components, the concept of components, of UI components to Drupal. And like, this is not something that was invented by the Drupal community or something like that. Like components have been a thing, like for a long time. And they got probably more popular

05:30
the configuration of JavaScript frameworks that we saw in the web. And like it is a nice way to organize and refactor your templates and your front end code. So at the high level, I think about components as taking some reusable code and sprinkling it.

05:57
all over the site, but I know that this doesn't make sense to most people. So probably others have a better way to describe components. Yeah, I might describe components as like a unit, like a small unit of a design, like an accordion or a button or a menu or something like that, that can be abstracted into isolation. But yeah, that just like you said, Mateo, like this is not a new concept.

06:27
And prior to using a single directory components, I think a lot of us are probably doing this pattern prior in Drupal and just kind of inventing our own system for that ad hoc for every project and tweak namespaces and what have you. But yeah, the module makes things so much easier and more, I don't know, official. Yeah, and that was kind of one of the main driving factors

06:57
trying to contribute this into core instead of just having it as a common practice at Lullabot, right? Because it could have gone that way. And the idea is that if we standardize on the way that we do components, then we can build as a community, cool things on top that integrate with components or allow you to tweak components or debug components and like...

07:26
all the good things that come with standardization. I wanted to also put a little bit more attention on something that Chris mentioned and was the word isolation. And I think that this is very important because in the past, I feel like we have been fumbling our way through

07:55
Adopting components in a way that they are isolated because of the way that Drupal works, where the templates get the data and like all that. So I think a nice benefit of using SDC as a standard is that now we can focus on writing isolated components are reusable and then worry later about, well, how do I fit data to this thing that I just made?

08:26
So we've talked a little bit about, I mean, it tried to explain what a component is. Can somebody give me an example, like a few different components that exist or you've built into your site, like what might be a component? I could give you a very simple example. For instance, one of the projects that we are working on, the links element that we are using on most of our templates, like for instance, you create a content type and this content type has a link field.

08:54
When we are rendering the link, we are actually calling to a single directory component called link, which is very basic. It has the URL and the title and maybe a few other options, but not much more. This is a very basic component. But the good thing is that- That's not a big deal. People can CSS style a link. Why does a link need a component? What are we doing special to a link?

09:21
I can give you a specific example of why. So then we implemented this component link everywhere on all the content types and all the micro content types. It's all over the place. So a few weeks ago, we were working on accessibility remediation. And as part of this, we decided that it would be a good idea to have an ARIA label on every single link on the site, not just the external link or links that don't actually have text,

09:50
in all of them. So all that we have to do is go to the link component and add an ARIA label there with the text that we are receiving and making sure that there are no facial characters or things like that. And that's it. Now every single link on the site has an ARIA label, which if you have to do this in a traditional way, you will have to go through several templates and find where there is an A tag and yeah, good luck with that. So it simplifies the process a lot.

10:20
So of course I'm asking questions that I know some of the answers to Javier because we've been on the same project now for a couple of years and Morgan's been on board too. I think Pauline stepped in for five minutes or so for a while. I don't remember there. There have been a lot of people rotating in and out of this project. But One of the other things we do with the link is we often style them, depending on if it's an internal link or an external link or there's a bunch of logic around the link field too that ends up getting encapsulated.

10:50
Inside this too, right? Yeah, yeah, in the end, now the link component is not as simple as it was when we started on that. So that's also the good thing about this is that you can iterate on a component and you can be sure that it will be updated everywhere where it's called. So we save a much of time for sure. A link or a promo or a card or a list or you know, each of these individual ideas get component ized.

11:19
And sometimes they're built with other components. You have small components that combine together to build the bigger components. So it kind of cascades from there. Yeah, and you can also use a concept of variants if you need as well, which we are doing. We pass a variant class and depending on the variant class, we call it specific template. So we can have, for instance, links that are specific for promo, links that are specific for paragraph of text or...

11:48
or different situations, apply different classes and stuff, depending on the context, which is great. Yeah, on the AppState project, we're using STC components in a similar way. To kind of give another example of a larger component, we have pages that use Layout Builder. So each row in Layout Builder, each region will have its own component. And then we also have like

12:16
more traditional WYSIWYG style pages where you can embed components inside. And we use the same SDC for both the layout builder version and the embedded in the WYSIWYG version, because they're the same thing. They're just different data coming from different sources in Drupal. But that really centralizes the problem, I guess, or the where you have to control everything in an SDC. And so like

12:45
half the time. I know when I first started working with components I was using the CL components module CL I think that's what it was CL components and now we're using SDC so what was the big change between those two?

13:01
Yeah, the CL components, it was trying to, it was our first attempt on consolidating our practices at Lollabot around this topic. And after looking at some of my Lollabot teammates implementations on their projects and my own implementation on the IBM project,

13:31
I realized that, well, we're not doing things so much differently. So I think it can abstract some of this stuff. And that was how CL components started. And then Mike Herschel, he lacked me, and that was my doom. He convinced me, he told me we should put this into core. I was like, ah.

14:00
That sounds like a lot of work. And like I've done core before with JSON API. So I don't know, but like as usual, he had good points and convinced me and helped me a lot dealing with the stuff that I didn't really want to do. I wanted to focus on the writing code and

14:29
maybe then replying to feedback, et cetera. So we did a tandem on that and CL components morphed into SDC with the help of Christina and Laurie and like trying to see, to do the exercise that we did when creating CL components from abstracting different

14:59
Lullabot projects approaches on components in different Lullabot projects and trying to see like, well, what would it look like for the wider Drupal community and like getting feedback on like this is the best approach and then also changing my mind on how things should work because that also happens every day. Pauline, I'll have you jump in here and

15:27
Javier and Morgan and I were on the on the same state government site And I know there was a point when we transitioned into single directory components Did you end up doing the same thing on your project or were you smart and started from the beginning with single directory components? My experience with single directory components was my first experience was with a project that was sort of like a like a research sort of thing like a

15:56
proof of concept, short engagement. And that was at the time when SDC just went into core. So yes, I don't think I ever truly used CL components or maybe I did just for a day. It was right at that transition time. How was the transition Morgan? I think it was pretty smooth. I don't recall, it doesn't feel like.

16:25
You know in practice that things are all that different from a front-end user perspective So I think you know I wasn't the one that had to switch out the modules and do all of that Heavy lifting so from my perspective it was pretty smooth. You did a lot of cutting and pasting right? There was a I know that there was a time when a bunch of developers were moving from here to there Yeah, and it was kind of the same but kind of different, right?

16:48
And that might have been when we were starting on the newer, the marketing platform project, we might've been switching right around that same time. I can't quite remember, but I don't remember it being too painful. So anybody still using it could still switch. Yeah, yeah, we switched from CL to SDC and once SDC was part of core and yeah, it was not painful at all. So if you're using CL, definitely look into migrating because it says,

17:17
doing some renaming and stuff, but it's not a big issue. And there's a lot of really good documentation on the single directory components page. So I really appreciate that. It's not always true on Drupal modules, so I can appreciate that. I'm glad to hear it, especially since it's a part of core, like it ought to be documented somewhere, right? And where do people find that? How do you, I know that there's the SDC module page and there's a lot of stuff written there, right? That there's no longer a module there, but it was kind of.

17:45
placeholder for where the development happened. That's where I've been finding all the documentation. I'm sure it links out as well, but you know, that's a good starting as a good jumping off point at least. We'll make sure we have links on the show notes. So one thing I understand exists, but I haven't heard anyone talk about yet is how components end up including other components, turtles all the way down. Is that pretty much how that works? We use.

18:11
Atomic structuring, but I don't know if you actually have to use atomic structuring if that's just how we do it to conceptualize I mean, what do you mean by that Morgan? Are you blowing things up or like what is where there's you know? Adams are your smallest components like links and buttons and things that are your most simplified components which then build into molecules Which might be like, you know a link plus an image or something like that And then that those all combined together to build organisms, which is going to be something more like

18:37
promo or you know a listing page of items or something along those lines, but I don't know if you know It needs that naming structure, but it's sure helpful So the the front end is is only slightly terrifying to me these days when I see things like that I've I've seen that naming convention used for a while. I've never known that that was the name for it though So atomic structuring. Yeah, maybe I just made that up. No you did not That was created if I'm

19:06
Remembering correctly by Brad Frost about a decade or more ago. Pauline, you might remember more. But yeah, it's just a system of organization. So there's no technical requirement that SDC requires that you use that convention. But yeah, it can be helpful in organization. Yeah, I think it's just been kind of like a natural progression, at least what I've seen from the front end. A lot of front-enders did end up.

19:34
adopting atomic design as a way of keeping things organized in your theme. And then having SDC come in, they just sort of play well together on top of that. And to your original question, Matt, so my, like my go-to example for an SDC, when I'm trying to explain it to other people or, or like paint a picture of it.

20:02
is like a promo card because those are on like pretty much every website. A promo card or a tout or a call out or you know whatever vernacular you want to use right? Yeah, yeah so it's usually like I don't know you can think of it as like a chunk of content there's often an image like a smallish image maybe a heading maybe a little bit of text and a link.

20:32
or a button of some kind or a button link. And that can be a component in itself. And then on top of that, you can, if you're using SDC for links, the way Javier mentioned before, then your links are going to be components being pulled into the card component.

20:57
And you can also have your images as a component in itself, if you want those to work in a special way, and that can be pulled into the card as well. And some people even go so far as to use headings if they need some kind of special markup for that to be pulled into the card. So it's like the card is a component, but then it's made of smaller components. Hopefully that paints a picture for like the more visual people who might be listening. So the card has a component of the button link.

21:25
that it's calling it. So the button link is included in the card. And there might be like a card title component too. Yeah, exactly. And it's all done through like the magic of Twig. But it sounds like that could be done with a series of Twig templates. What does STC actually do to improve this process? That's like the cool thing about it is you can create these

21:54
robust and adaptable twig templates that you can then plug different data into in different contexts. So this is going to be a totally random example that probably makes not a lot of sense in the real world, but let's say all of your promo cards on the home page have blue borders and the promo cards on your internal landing pages have red borders.

22:23
then depending on the context where they're being called, you can designate that change without having to have multiples of the same template or basically the same template. Use the same template and just plug in variables. And I suppose one thing I should point out is that we're still using Twig templates, right? The Twig template calls a component essentially.

22:50
Yeah. So what is the makeup of a component? I don't think we've ever talked about that yet. We kind of went cart before the horse here. So one component is is a directory, right? It's a single directory that includes what? Yeah, well, Matteo, you can correct me where I'm wrong here. But it has a few different files in there. So one is the tweak template file, which, you know, accepts the properties, you know, has has

23:19
You print variables for the properties that you're accepting or the blocks that you're showing, which I can get into in a moment. And then there's also a YAML file, which is like the manifest, like the definition of what the template accepts. So each property, what type they are, if it's a string, a number, an array, that kind of thing. And also what slots there are. So that's like what the block is. So like, if you're familiar with like the Twig embed,

23:49
tag where you can give properties to the template to pass variables directly that way, but then also have a block named, any number of named blocks that then pass in a chunk of markup, which can be really useful with working with Drupal that we found actually having to designate between those two. And then also, in addition to those two things, you can optionally have a CSS file and a JavaScript file.

24:18
Um, and both of those things are kind of automatically set up for you so that when you include that SDC, wherever, like with a, uh, twig include or an embed or whatever method that you're including it, um, SDCs does all the work behind the scenes for you to include that CSS file or that JavaScript file in place. So working with the Drupal asset management system and bundling that up in all the ways that you would have had to do manually before.

24:48
but it's only included on the places where that tag is included or that component is included, which is really useful and a nice performance win and also something you just don't have to worry about. Like I know my styles or my script will be included whenever I include that component. I think that's the big thing that I like is that your JavaScript comes along for the ride so long as you've set it up correctly. Yeah. Yeah, I think that one of the biggest

25:17
benefit of single directory components is the simplicity of it. Because as you say before, you could pretty much use it as a tweak include mechanism if you want for calling other templates, or you can go all the way and add JavaScript and even a style if you want there. And also there is this property that you can set up on your settings.php for making FTC to enforce your metadata.

25:47
and probably Matteo can speak more about it, but it will make your site to throw an error, for instance, if your data doesn't match the whatever you set up on the schema, or you can leave it like pretty permissive, which the schema will describe it, but it will not be enforced, so there will not be errors if you, for instance, pass a null value or a different type of data value. So you can use it as you want.

26:15
basic as it fits to you, which I think is actually a good thing in this case.

26:23
I want to call out a couple of things. One is that I love that Matt said that the best thing is that JavaScript files come along and forgot CSS because he's as much backend as I am. And also the idea that- To be clear, CSS comes too, right? It does, it does, it does, yes. And also the idea that-

26:53
we are not including a Twig template. Like I forgot who was alluding to it. I think it was Chris that we used to include Twig files as well. And now we include components. And that means that we had to invent a new naming convention, which can be less intuitive at the beginning. As like, I'm gonna pass, I'm gonna do this include in my Twig, I'm gonna pass it.

27:22
the path to the file of a tweak template that I wanna include, right? That's very straightforward, the mental model of doing that. And right now we are not including only a template. We are also including those JavaScript and CSS files, right? So the solution that we came up with was to do this.

27:49
naming convention where you pass the name of the provider, which is just a fancy way of saying, like the component is gonna be inside of a module or a theme. So you pass it the name of the module or the theme that provides your component or that declares your component and then the name of the component. And then there is some process in the backend that...

28:17
goes and finds that component and finds that underlying path to the file, to the trick template, but also to the JavaScript and CSS and thus all of the processing for you to include everything. So that's why your ID does not out complete the component that you want to put because it's a new naming convention, right? And...

28:46
The other thing that I wanted to call out is about the schema. The schema that goes in the component definition or the manifest as someone called it and I love it is also going to be the integration point for all of those cool things that we can now build because we standardized on the way that we do component.

29:15
that I was alluding earlier. And by describing the input data that your component takes, like for instance, the link component, it will take a URL, right? You can describe that the URL is a link that it takes the form of a URL and then say that it needs to be there for the component to actually work. And you can describe that and the re-documentation and how you do it.

29:45
We use JSON schema, which is a standard that already existed. Ironically, we use JSON schema in YAML, but YAML is just JSON, right? It's all the same, right? Just, yeah. Structured data. With comments. Okay. And in, yeah, by describing your data, you can make your component or you can...

30:14
raise awareness of what your component does. And I could, for instance, generate a form for that link component automatically, knowing that, oh, this component takes a URL and then a title and then a Boolean to that knows if it's external or not. And then like do integrations like those. So.

30:42
The enforcing schema that Javier was mentioning was to make sure that you write the correct schema, right? Because if you do, you're gonna gain so much down the line. And now I'm thinking about experience builder, right? And things like those which are going to build upon as they say. Cutting edge. I like it, Mateo. Always thinking about the future.

31:09
We're talking single directory components on the Lullabot podcast with a host of Lullabots that seem to know everything about it. And we'll find out more. We'll talk about integrations with other tools and any sort of challenges that folks have come up with, problems they've had right after this.

31:28
Welcome back to the Lullabot Podcast. We're having a conversation about single directory components with a handful of Lullabots here. So we have Mateo, who I think we can claim is the inventor on the line. Mateo, you also spent a lot of time with JSON API and other work that has gone into core. The biggest question is, where do you find the time?

31:57
Well, actually, the time and the patience, I think it was inherited my father's patience, but I didn't do much for for SDSC. Honestly, it was easy to work towards getting into it, into Core, because like we had these experimental plan. And as for the time,

32:27
Uh, these was just build in time that Lollabots sponsored me. Like we have some internal time allotted to just do stuff. Right. And this is the stuff that I did. Some of us make podcasts and that's a whole lot less useful, but more fun. In my opinion, I am not the judge. I just have my, my fun.

32:56
writing code, I guess. So Mateo, are you going to be speaking at all about single directory components? I have been. I have been speaking about single directory components. And the nice yet sad thing about it is that I feel like it's all news. Like people are using it. And it's not something that I need to like keep on going to events explaining. People are doing their own.

33:25
their own sessions on single directory components and how they are using use cases. There's a ton of content on it. So I'm just happy to step back and let people that actually use it because I've been put in this role of telling front-end developers how they should work with JSON API. This is how you're gonna make requests.

33:54
we're using JavaScript frameworks in Drupal or at least how you're gonna use components. But these have been just my proposals, but people that actually use it are the ones that should speak now, I think about it. So one of the questions I had with our previous segment that came up in my mind is should a contrib module developer be providing components for other folks to use?

34:23
How does this work? Yeah, yeah, totally. Well, I think so. And my idea is that if we do that, we collectively start building this repository of components that you can just add to your site, be it through a base theme, and then we could talk about...

34:50
like generic components that can be themed, that are provided by base themes, but also like Drupal modules often need to put stuff in the page, right? And- That's kind of the point a lot of the time, yeah. Yeah, and while it is one of the rough edges of SDC to have them work with form API, similar times,

35:19
modules do add things in the frontend team, right? And that's when I think it makes the most sense for modules to use SDC, because then it allows the site owner to take that component and adapt it to their liking, because that's something you can do as well. Take a component that someone provided and change it. And it still works for that module.

35:49
So tell me about the integration to Core. Matteo, you called yourself out as a backend developer like myself. I haven't cracked open and looked at the code. Do the base themes have components, or is Core providing components somehow? Or is it just the structure for the components, and then you have to do your own work at this point? Yeah, Core is providing some components, and I would encourage anyone that

36:19
start contributing into Drupal core and has an inclination to write components to do so because we probably can do it more. This is a relatively new tool and compared to the lifespan of Drupal. So we probably could use them more, but things like the navigation module that some other Lullabots worked on.

36:47
are gonna be leveraging components. So more and more of the new development or code that gets out into core and to Drupal CMS will probably get components. And even though those are...

37:07
somewhat ad hoc for the task, and it's not the aim of those components to be reused in other parts. You can certainly do it if you're happy with what the component looks like. Will there ever be something like a component library that we can like browse and kind of like take from in Drupal Core? Like I know that, or I know that SDC pairs with...

37:34
you know, like Storybook and other component library services. Is that something that we might have one day? Yeah, I hope so. And we may be getting into TripleCMS territory and the product development that is happening there. But as Lollabot, we have been forever working with

38:03
nice design systems and we've kind of specialized with it. And the challenge for having a component library for Drupal instead of for a project like we keep doing in our projects is that has to work for everyone, right? And like, well, it's nice to have a standardized solution. It's also hard, but...

38:32
That being said, I think it will happen. I I'm rooting for that. I appreciate the optimism. Hey, would somebody walk me through storybook and just kind of explain what that is? I know that it was something that I've seen on projects. Uh, before we were STC, we were see all components. Storybook was a thing. Um, explain what it is and how, how it gets used. Yeah, I can explain storybook. Um, so storybook is another piece of, uh, software. Um,

39:00
that you run locally, it's an open source project. And it demonstrates components. So it provides like a browser interface where every component that you register with it is listed in an UI menu system and every property to the component is exposed. So a property is just any piece of data that you would pass to your component. Like if you had your button.

39:26
You might have a property as the text that appears in the button, and you might have a property that is the link, or the action that happens when you click the button. So Storybook just provides a way to demonstrate all those components visually. It's really handy for showcasing the state of all the components to the entire team. You can stress test them by falling on the keyboard for every property.

39:55
passing that in and that updates live. And it's also a great place to do documentation, because not only does it demonstrate each component, but you can demonstrate them in a markdown file, which then becomes documentation. So you can kind of explain like when and why to use a particular component, which is really helpful for a lot of projects that have like complex systems, complex design systems where there's requirements about

40:24
where and when to use those components from design that are not going to be hard coded. They're not implemented in code, but they're soft rules, but you want to have a place to showcase that. And it's very useful to document that right alongside the component that you're explaining. And Storybook generally lives outside of Drupal.

40:49
So this is a place where a lot of projects or teams will use it as maybe like, I kind of hate this phrase, but like the one source of truth for like the way things are, the way each component is supposed to look and like which properties they accept and how they change a different screen widths and things like that. So developers, designers, and anyone else that's involved can...

41:18
should be able to access Storybook for information that they're looking for testing.

41:25
Right, yeah, I think that one of the beauty of this design system UI, like Storybook and PatternLab, is that you can build your components in a context-agnostic way, because you can basically build your HTML CSS for your component, have it showcased either on the Storybook or PatternLab or whatever other place, without having the backend actually done.

41:55
If you haven't done a content type or you don't even have a backend yet, you can start working on the daemon side and validate it with designers and clients without actually being on an actual platform. In the case of a storybook, SDC makes a great job of connecting with it without you basically doing anything. There is a contribute module. What you can achieve with this is that you can actually start working on your front end

42:25
before the backend is actually done. So if your components doesn't contain any Drupalist or saying in a way, like it's not accessing node objects or things like that, you can pretty much start deeming your components before the backend is done and actually have them rendering on the storybook and making sure that they look good and all that. And once the backend is done, all you have to do is to plug it with your company.

42:52
either through a template or to display options or whatever other mechanism there are. So yeah, it's very helpful. Yeah, and that's why I called out the word component in isolation before, because if you don't have any triple specific filters inside of your component, which in my opinion you should not have, that those should be used before.

43:20
the component and then the data that gets fed to the component is just strings, integers, Booleans, et cetera. So, yeah, with Storybook, what I like is that you can have all those inputs that we were talking about before exposed to a user, that would be the QA engineer or a stakeholder or...

43:48
whoever wants to look at those components and play with those and also has the concept of kind of a bookmark of settings. Like once you have played with, let's say you have a component for a grid of cards, right? You could have like, oh, this has these so many elements and that you can take like a bookmark of it and then you have what they call a story, right? So...

44:17
You can have a URL where you can look at that component, maybe a button that has the primary boolean toggled on and then the primary boolean toggled off. So two different URLs, which opens a ton of possibilities. Like you could do visual diffs on that page, right? You could use something like taboat and do visual regression testing. And you could also

44:47
use some of the many Storybook plugins that can take a look at that component, how it's rendered, and say, oh, look at this, you have poor contrast in this component, and this is not good for accessibility. And like, the Storybook community is gigantic, and there are so many plugins that is like, go take a look, I don't even want to...

45:16
I mentioned any plugin in specific, but it doesn't let you do a lot of cool things. Very good. I think we're coming to the end of our time. So if anyone has anything else they would love to say about their use of single directory components or anything that they wish it would do a lot of times on the podcast, we talked about the blue Drupal genie that granted a wish or, or something like that.

45:40
If something you enjoy or something you would love or something that challenges you about single directory components, I'd love to hear that. So Chris. So this is something that we learned in the project about how to work with single directory components was the boundary between properties and slots. So properties being what I explained before about like just pieces, singular pieces of data being passed to the template. And a slot is like maps to a twig block.

46:09
which is just like, instead of passing a specific, like primitive value, it's just like a bucket where you can pass in any markup. Or really, it's just, it's not checking anything, it's not doing type check, it's just like, here's the thing and you pass it in. And this is just actually something that we were learning with working with Drupal itself, like how to pass in data, because there's parts of Drupal where you're at the integration point.

46:39
it doesn't give you a primitive value. And we were trying all sorts of ways to kind of distill it down, but the solution for us was to use a block. And the example being like a larger component that also contains an image. So like a promo kind of call out type thing, we use a block for that image and just accept the whole chunk that Drupal gives because there's all this kind of

47:06
extra templating and rendering that happens, like with responsive images and just divs wrapping around it and like picking that apart at the component level or where in Drupal we would do the template or a pre-process. It was getting really hairy and kind of like anti-Drupalisms and stuff. So just pass the whole thing in and let it render as it renders and style around that. Javier, do you have any final thoughts? I think that

47:34
Something that I would like to see, I know that this is a work in progress, but the ability to link or assign components directly from the display options for your content type. Sorry. So instead of having to do a template, a Drupal template that will connect your SDC with your field or your content type, you soon will be able to do it. I'm sorry if it's not soon, but at some point you will be able to.

48:03
connect those directly from the display options for your content type where you will go and for instance say okay this image field rendered using the image component and here is how you should map it and I think that would be a big deal because we would move from having this kind of pair between components and data from templates to configuration.

48:30
which I think is a much better place for it to be. And it will prevent issues like cache metadata leaving, being left out and that kind of thing. So that's something I'm looking forward to. Pauline? If the blue Drupal genie could grant me any wish for SDC, I would have SDC vacuum my house, do the laundry.

48:58
Um, do the dishes and pick up my kids' toys. I'm with you. Matteo, this is something you have put out into, into the world and, uh, seen it, seen it be adopted by everyone. Um, final thoughts from you. I'm so caught up with Pauline's blue genic wish. Um, but I think that I'm going to go with.

49:25
If you are working with SDC and like figure out something that was not immediately obvious or like consult with anyone on how to do something SDC related, there is a frequently asked questions page that anyone can edit and put something there. Or even if you have a question that you like think.

49:53
How is this not in this page? Just put it there and put it TBD and then ask in Slack, hey, does anyone know how to resolve this? But yeah, let's make it together the best documentation that we can have. Is there a space on triple Slack where SDC people hang out? There is, yes. It's called the Pound Components channel.

50:22
There is a lot of activity on Sdc and also the UI suite of modules, which is so cool that it may deserve its own podcasts. Ooh, we're going to hold you to that Morgan. I think this podcast has been a single directory component. Yeah. It's a list of cards. It contains everything it needs. We have four aces on today. Yeah, absolutely. It's been great. Always good when Lullabots join the podcast and let's do more of this, huh?

50:51
Yeah, it's our goal to go every other week. Yes. So we're going to do it. Thanks, everybody, for being on. I appreciate it. Yeah, thanks, all. Thanks, everybody. Thank you.

51:09
Bye!