About this talk
This talk covers the concept of Single Directory Components (SDC) in Drupal, which simplifies the process of component-based theming. The speaker, Jennifer Dust, highlights how SDC allows developers to consolidate Twig templates, CSS, and JavaScript into a single component folder, making components reusable across sites. The session also explains the structure of a component, including essential files like component.twig and component.yml, which dictate how components are rendered and how data is passed. Additionally, the talk introduces SDC display, a module that streamlines the integration of these components without the need for complex Twig templates, thereby enhancing collaboration between developers and site builders. Dust emphasizes the practical considerations when using SDC and SDC display, providing advice on when to implement these tools effectively within a development workflow.
Full transcript
I've got a link for either on the screen right now, so that's at bit.ly/breaking-the -theme -barrier. Or if you go to the Drupal Con 2026 session, they are at the bottom of the session information. So, if you want to download them, they're available. You can follow along or you can get them later. We are all good. I'm going to scoot this a little bit. Okay. Cool. So,
obviously good morning and welcome to Breaking the Theme Barrier. This is simplifying Drupal with SDC and SDC display. So, throughout this presentation, we're going to talk about creating single directory components and how to use them dynamically through Drupal's admin UI. My name is Jennifer Dust. I'm the director of engineering at Aten Design Group. My background is working with higher education and non-for-profit organizations. And I can't believe
to say this, I've been contributing to open source for almost 15 years. And which is wild, and I also help lead the Women in Drupal group. So, if any Women in Drupal here want to hang out, hello. Um my organization is Aten Design Group. We've been around for about 25 years providing digital strategy, design, and development for open source mission-driven organizations all around the world. We worked
with a number of government, higher ed, and non-for-profit organizations like these. And we're passionate about doing work that matters. So, I'm excited to talk about single directory components or SDC for short. I'm going to use that shorthand a lot. You'll see it in docs and comments, and SDC is kind of the the name we're going with. So, this is a relatively new technology to Drupal. It represents
a shift in how the community can approach component-based theming. But two far into this presentation, I want to ask a few questions with some show of hands. How many people here have never used single directory components before? Oh, okay. All right, so a number. Okay, cool. Awesome. I'm actually super excited you're here cuz the more people I can talk about this, great, fabulous. If you can't tell,
I help add some of the docs on core and I'm always happy to see more people interested. On the flip side, how many people do we have here with a site currently using single directory components? All right, so a few. That's good to know. Well, hopefully, you know, if you're already familiar with SDC, you're going to learn something new with SDC display. And if you're not familiar
with SDC, I'm really happy you're here. We're going to talk through creating a component all the way from start to finish. What does that look like and then where can we go from there? SDC itself has been around as an experimental module for a while, but was officially released as stable with Drupal core 10.3 and beyond. So, anyone who's on 11, it's already included in core, you
don't have to do anything. It came about as a solution to address the issue of having Twig files in one place and styles in another and JavaScript somewhere else, effectively allowing all of these to be consolidated into a single component folder. I know. Hence the name, single directory components. We're very creative. It's Because it's self-contained, each component you create can be reused, effectively copy and paste, and
dropped into another site, assuming it is also using SDC and/or similar This already, I hope people can kind of hear that and go, "Wow, that's That sounds like it could be really useful." It's really one of my favorite parts because I can create these components, I can actually build them out as a library of things that I can pull from as a developer, which in turn has
really changed the way that I support my clients, the way that I, you know, show up with building sites because I have this backlog of things that I can go, "Oh, you want this really complicated thing? Well, I already built it." Great. Everybody's happy. Now we just got to style it. Um so in addition, SDC did something that's really unique in the fact that it introduced automatic
library creation for these components. And that means that Drupal's effectively going to look for your CSS and your JavaScript files inside the component folders and add them to an automatically generated library. So, I'm pretty pumped about this as a front-end developer because that means I don't have to register every library file within my library uh YAML file. It's just going to adapt and add those for you.
In addition, you can also add um other assets and dependencies within your component.yml file. So, if you want to add animation and you're using the GSAP library, if you want to add complex JavaScript folders or interdependencies, we can add all of those inside that And we're going to dive a little bit more into that file specifically here in So, let's back up and take a look at
what's actually inside the component I've got two images here up on the screen. Components live within the components folder located inside your Drupal theme or module. They do not have to be used within themes alone. You can use and create modules. On the example on the left here, we're looking inside a custom theme called prototype and highlighting that components folder. So, I've got that red kind of
box around it. This is where Drupal's going to look to register your components specifically in your theme. So, web, themes, in this case, right, custom prototype, components. You can have, I know some people like using the atomic theory, the atomic folder structure. You can do whatever kind of folder structure you want, so long as you have that components folder. Components only specifically have two required files. This
is the component.twig and the component.yml You have the option to create the style files and JavaScript files that I talked about earlier. And those again will be automatically added to the component, keeping everything self-contained. If we look at the example on the right, I've created a simple card component with a card component.yml, that's required, card.css, and card.twig, again that required file. It's important to note that the
names must match. your Twig name, so card.twig, and your component.yml file they must have the same name in order for Drupal to recognize it and register it. You can add other names and, you know, fields in here if you want, but then they all have to be registered within that component.yml file for it to be registered. And again that applies to styles, the JavaScript, you can do
a whole lot in here. We also you're not stuck with using just CSS. If you like having Sass or some other pre-processing system, a lot of what I use I have a source folder inside this component, and that's where I have my pre- before I've compiled anything I've got my, you know, CSS file, my JavaScript file, and I have actually a build action that when I deploy
my code it's going to create the CSS and the JavaScript for me. I talked about Oh, that's kind of hard to see. I talked about the component.yml file. I've got an example card component up on the screen. If you really can't see it, I hope you've got a device that'll let you read it. Seems kind of faint. The lights? Can we dim them? Does anybody in the
back feel a note? Okay, well, I'll walk you through it to the best of my ability. When Drupal scans the component directory, it's going to read each of these files and its definitions. The component.yml file is going to tell Drupal how it should work. Every component uses this file, and this structure is a contract with Drupal, if you think about it that way. Drupal will use what's
written in here to enforce the structure outlined whenever you're sending data into this component. Because of that structure, developers, we can use these detailed outlines as a as something that we're expecting to see, making them easier to use and understand throughout the site. When I'm building out components like this specifically and it like for example, if I'm waiting for back end, they're working on building out the
site, I know that if we've agreed on the data structure, I can go, "Okay, well, this is the type of data I'm expecting you to give me. I can start working on a component right away." I've outlined here in red the very top of the file, the first couple of lines which are metadata about the component itself. So, we've got a schema which describes the structure that
is allowed in this file. I do want to call out that while schemas are not mandatory when defining components in themes, components without them cannot be overridden. They can't use modules like SDC display or UI patterns. And a reason that that's important is if you are creating a base theme, let's say you have a lot of sites that you manage and you're creating a base theme, you
would want your component to have the schema here so that maybe you need to override something in it and whatnot. It can't do that if that is not there. So, you don't have to have it, but good rule I would just add it. Next up, we've got the name which is how the component is going to show up in your system and how you're going to reference
it in templates and I'll show you that in a minute. While descriptions themselves are not required, I recommend adding them to your components or either around the data they support or how they are intended to function. We've got a description on our card component up here and it reads a simple card component with a heading, text, and link. This is actually super useful because it lets me
know as a developer, just by reading that alone, that this component does not support an image. Right? If I'm thinking card, maybe I'm thinking, "Oh, okay, this has an image." It doesn't, at least according to the description. Group, right underneath the description, group is the group of components that this might relate to. So, it could be helpful when you're setting up and working in large-scale design systems.
So, if you've got something that is a you want to call it, you know, an element, and this is a baseline component, and this is you know, iterate on that, you can use groups for that, and that's really going to come in handy when we get to the second half of today's presentation. Status has a few options. You can use stable, experimental, deprecated, or obsolete. I would
recommend using status when you're working to build out component libraries specifically so you can keep track of changes or improvements within components. A lot of the times I've used this when we've changed or iterated completely on an idea, and maybe we we can't quite get rid of the old version of the component, but we've got a new one. That's when I might mark that as deprecated. Before
we keep going in this file, I do want to take a quick look at props and slots, which is really truthfully it's the rest of the file here. It's a lot of stuff. This is a question that I've heard frequently from a lot of people who are working with SDC. What is the difference between props and slots? How many people here actually know or feel really confident
to answer that question? Okay. All right. I love I love the confidence. Fabulous. Well, we're going to do a quick breakdown so that you don't have to sit here going, "I have no idea." Cuz I really didn't for a while. Props are for data whose type and structure you know. So, what that means is I could have a that I know is a type of string. I
could have a link that I know is an object, or I could have a custom field called show icon that I know is a boolean. For each of these, I know what that expected data type and structure should be, which is why I would make them a prop. So, on the right-hand side, I've actually got a zoomed-in example of what writing inside that component.yaml file would look
like. This is for that heading field again. We know it's a string. I've given it a title of heading. And you can actually provide examples of what the expected content might be in this component. And that's actually really example important. So, I've added this is a super cool example card heading. Thank you. So, what does this actually look like together? Going back to this card component, you
see that that's the bulk, really, of what's on my component up here. I've outlined it once again in this big red box. And we can actually see that we have our props key first, right at the very top of the far left-hand corner, followed by type object, and then properties. Those are really important keys that you need to make sure your component has when you're adding props,
because our props that we've been talking about don't actually live directly under the props key. And I know that seems a little bit silly. They are going to live under properties. So, where we've got props, object type or type object, properties, here's my here's my props. And I've got three different props being set. Every single one of these is expecting a Except that they're different content in
regards to that string. And this is exactly where I was talking about having either descriptive titles or examples are ideal, right? So, we've got that up there. I want to make sure that my heading, I I that I'm expecting, you know, super cool heading. Versus my body text, which is a lot larger. I do want to call out for people with your first time playing around with
SDC. If you have the incorrect indentation, this is a YAML file like all others. If you have the incorrect indentation at any point in this file, um it's it's going to yell at you, politely. So, uh just double-check your placement in your key, double-check your spacing. Uh that's probably the first place that I would go if you're like, "Why does this not work?" And it's salty, that's
all right. Maybe. And so, we've also got this descriptive title, which is going to come in handy later when we start mapping through the UI cuz that's going to end up getting exposed. Okay. So, what about instances where we do not know what our data type is going to look like? That is where slots come in. So, slots specifically are for data that you do not know
its structure. Meaning, it could be an array of objects. It could be straight-up blocks. It could be other nested components. You can nest other SDC components in those slots, which I do frequently and it's very helpful. To add your slots to the component.yaml file, they need to be listed under the slots key with their name followed by their title. And we'll we'll take a look in a
second here. In our example here I've got on the right, we have two slots, one called image and another called links. Because these are slots, again, they can have different types of data passed into them than what you might think. For example, if I had an image, maybe it's actually a slide or a piece a slide component or it's maybe it's a piece of media or a
figure or whatnot. The same thing with links. It doesn't have to be just it could be is that a series of links? Is that a list of links? Is that a bunch of buttons? So, that's the benefit of having slots. You can just kind of send them on your merry way. Choosing when to use slots and props entirely depends on your data structure. Drupal will validate against
whatever you create in that component.yml file. So, if you list a prop with the wrong data type, you are actually likely going to end up with the lovely white screen of death. The white screen of death is happening because Drupal's actually validating that prop max it matches the data type exactly. So, whereas slots it's really just checking if it's empty or not. So, I mean it you
know, use your powers for good uh cuz Drupal doesn't really know what's within them. So, slots true false kind of mentality props is this exactly a string? Is this exactly a boolean? There's also a module I would recommend you test using for this. It's called SDC Devel if people are familiar with the Devel module when writing components because it will actually help you validate this the component.yml
file and your Twig files because it can also explain some of the errors. I know right now I feel like some of the error messages that SDC prints out are not necessarily the most helpful. That module does a really good job with helping you walk through that. I have added a link to that module in the resources slide at the end of this presentation. So, don't worry
if you're going to forget. All right, back to our card component. So, if you take a look here, I've outlined once again in that kind of middle part of the the layout here a red box. We have only one slot. You also don't have to put these in that specific order so long as they follow the right semantic following, you should be good. In this case, it
supports a link slot, which means we could add again that nested button, a list of links, or a link prop itself. So, how does this relate to the components in the overall content? There are a few different ways we can attach SDC components. One way, if people are interested or you've already done this, is programmatically through a render array in PHP. Uh today though, we're going to
talk about attaching them with the include statement that I've kind of got up here already. So, an include statement, if you're not familiar with this, you can connect pretty much Come on, it's pretty much any display within any kind of Twig template that you've got laid out here. I have created a paragraph called card, and this is inside my paragraph template that I'm adding this temp this
include statement. So, the statement inside my custom paragraph, we've got includes prototype colon card. That is the expected pattern whenever you are adding an SDC component. Now, you don't have to use includes, you can also use embed. I'm just going to use includes for simplicity for today. Um, but our docs have a really good explanation on how to do that. So, we've got our module or theme
name, right? So, right now I'm in a theme, but I could be in a custom module, and colon name of Once you have your brackets in place, right? I've got my curly braces, we can actually start to map out our data to the fields that we already aligned those And we can pass those into the component.yml file knowing that heading text, and link are all strings. I've
got a default set here because heading is a required field on this component. The last thing I want to call out is you'll notice at the very bottom I've got with underscore context equals false. This parameter is tech maybe optional, but I recommend using it whenever you can to prevent kind of funky issues from happening. I've had random attributes get passed down. I've had incorrect data get
sent to a component. So, I just rule of thumb without with context equals false everybody's happy, and it and it tends to behave really nicely. This is also I found the with context is important if you're using a visual editor that relies on attributes, too. I've had issues where attributes don't play nice if I don't have that. Okay. So, we have mapped our content into our component,
and this is actually an example of what it looks like. That looks very white. Okay. Um so, we have it side by side, our Twig template, our card.twig template on the left, and we have our component, our style list component on the right. And I've added arrows showing you kind of how they line up. Now, because text and heading and link are all technically strings, I could
put any data into I any of those props. They would still validate correctly. They wouldn't look right, but they would validate correctly. And you'll notice I've got block links, if link, and then I have my actual link wrapper. The if link is just validating if that prop was set or not. The block links is the slot. So, that's the piece in my Twig template, very similar to
Twig blocks where you've got That's my slot. So, that key right there is going to map back to our component.yaml file. That's a lot. STC gives us these reusable, dynamic components that we can kind of drop, play, and mess around with, but is there a way to connect them without writing that custom Twig we saw every single time? I don't really want to modify Twig templates always
to map my That's where STC display comes in. So, STC display provides a simple interface with a direct solution that allows us to link components through Leveraging Drupal's admin UI, it helps break down those theming barriers, making components more accessible, especially if your team doesn't have a developer on staff. Like, maybe they can make the components for you, but you don't have the time or the availability
for them to constantly make these iterations and connect new pieces of your site to existing components you might have. With SDC display, you can manage the components without relying on those custom templates, which helps keep the code base clean, and that makes me happy as a developer. Um in addition to connecting components through the UI, you can display different types of components just based alone by view
mode. And you don't need custom templates for every single thing. So, you can have different view modes, you can have multiple different types of content all point and share the same kind of component. So, you might have a node and a paragraph and an entity and they're all actually using the same thing, they're just getting there different, and you don't need a custom template for every single
one. There's a lot of flexibility with mapping components this way, which is what makes SDC a really powerful tool. All right. We're going to take a look at how SDC actually works, and it functions SDC display. It functions very similar to SDC itself in the sense that it's automatically identifying components within your site, including both themes and modules. Then those discovered components show up in a searchable
list that you can map your fields to in the manage display tab. The manage display tab, you can then connect those fields to the props you've defined in that component.yml all they're going to show up. And as long as they have the exact specified data structure, you can pass into it. If you try and map to something, it is going to throw a white screen. It's going
to happen. It happens to me a lot. Well, more than I care to admit. once we've mapped our You can also map your content into slots, and that is what makes SDC display super powerful. If you want to nest components, and you maybe you have a layout that you want to map to a layout, and then inside that layout you've got a card component, and you want
to link. You can get pretty granular with mapping at the field level, and we will I will give an example of how to do this. So, for a component overall, we've got view modes, we can map our fields. We can map slots. Uh woof, all right. So, that's a lot to throw at you. We're going to walk through these step by step. I do have these next
couple of videos recorded in the slides. If If we go too fast and we're not able to follow along, don't worry. They're in there. All right, so going back to our card component that we created earlier, this time we're going to attach it via not via Twig, we're going to leverage SDC First, we're going to navigate to the content that we actually want to connect this component
to, which again can be anything, so long as it has this manage display tab. In the example, I've gone to my manage display tab for the card paragraph that I talked about earlier, and I've scrolled down to where you can kind of see you know, you can't, but single directory component options, and I click that on. So, this is going to give me a lot. It's going
to pull from both my theme and module to all of the available components I have. You can look through this list, or in this case I'm actually going to use the search field and look for our card component, and it's going to auto filter, which I think is jarring, but it will narrow it down to two components, and I'm going to select the one that I was
looking for. What's also nice is that SDC display when you're viewing your component, it will provide you the option to view more information, so that's the ID, the status, the group, and the readme file will be rendered here. There's also There's currently an open issue on core to support the thumbnails, so that's not done yet, but you can do pretty much everything else. You can read through.
I'm convinced this is the component I want, so I'm going to scroll down to the props section, where we're actually going to do the mapping. The cool thing here is I can have a component that accepts a lot of different props, but I only need to map the ones that I want to use with this content. So, I've mapped heading, text, and link. I'm saving here, and
then we're going to actually go back and refresh our content. So, right little blocks. Wow, they're styled. That's it. That is how easy it is at the very baseline to get these components actually styled and put together. Through the UI, I had done it previously with that Twig template. A couple of clicks, the view mode I chose, and I could use a different view mode for if
I wanted a teaser on a node, and I wanted to have a specific stylized search teaser element across all my stuff. You can use the same component. It doesn't care as long as the data is the same. We're going to take a look now. We've mapped out that component. Let's look at some of the other options you can do So, let's say instead of this button style,
instead I actually want it to be a link. And, you know, this is nice and all, but so I'm actually going to go back to the manage display, and on the link field itself, I'm going to go in, and I again, once again, I can click this render as component. And it will show me all of the components. So, now I'm doing it on individual field level.
So, unlike before, I'm going to just search for link. I'm going to click on Here's where it's different. When I'm um I have to map a specific prop or slot that gets the data that is being rendered. It's only going to pass it to one thing. So, I'm going to pass my link data into link. This link component supports an icon. I'm not going to set anything
yet. And I'm just going to go ahead and update, and then I need to come down here and unmap my link, and select my link slot. Cuz I want to pass something into that Once I go ahead and refresh, we're going to see that this button, whoop, it drops away and now I have a link But I really liked that icon I had in there, right? So,
we go back, we open it up again, and this time I'm going to go to fixed values. These act as fallbacks when the component does not have data being passed into that field. So, because I wanted to pass my arrow right, I'm going to save my page again, refresh, and I'm going to see, whoop, there's my arrow right. So, you can do this on as many fields
as you want within your component. I mean, use your powers for good. But, you can map, you know, if you've got nested content that you want to make sure it displays a very specific way, you want certain buttons to show up on other components, but you want the base component, that's where the power of having a base prop versus having those slots that you can override really
comes in handy. Now that we've kind of covered over how SDC display works, the next big question is, when should we actually use it? And when should we not? Let's start with when we I would recommend using SDC display. I think it works really well for design system-driven projects. If your team is rebuilding usable content like cards, teasers, heroes, slideshows, and you want to be able to
leverage site builders to dynamically choose how that content is rendered, SDC for sure, and then maybe try out SDC display. See how it works for your use cases. It's not going to be the answer for every solution. It also seems like a really good fit for me in terms of any kind of structured site. If you're using something for enterprise, that's the content is always very clearly
defined, and you need to give editors or other site builders access to components, and they need to be able to make these things happen fast, that's another good use case for leveraging SDC The same thing is if you've got multi-view mode, so you've got contents you want to render in different view modes, you don't have to create those custom templates every time and then go and map
it and then code push and deploy. You can just make those changes through the UI. realistically, that's pretty useful. Uh it but it really comes down to the content that you have on the site. When would I not use SDC display? So again, this is content driven. If you have highly complex conditional rendered logic, right? So meaning that your component needs preprocessing, it has specific conditions or
logic based on user roles, permissions, complex data relationships, I think truthfully you might be better off with Twig and preprocess functions. Now you can try it. And and you can use it. You don't have to use it for everything. That's the other benefit of SDC display. You can use it in a couple areas of the site and then not use it at all. We've got several clients
that I've worked on where they have it for a very few specific couple of things and then the rest of the site might be more bespoke and that's when we're leveraging the tools that we already know. A simple kind of rule I would use is SDC display is meant for common patterns. It's not a tool that's designed to replace all theming right away out of the box.
Um so, if you're going to use it, UI driven, component based and avoid it if you've got complex or dynamic logic. we kind of talked about how easily it is to map those components using Drupal's UI. Then it kind of goes into how does this actually impact your teams and workflows? Leveraging both single directory components and SDC display doesn't just simplify your overall code organization, it really
allows you to change the way your teams collaborate. We kind of touched on this briefly in a few ways that you can update your workflows where developers it's going to help us out and site builders and maybe even designers or feds. But let's see how actually they could work more efficiently together. I've got up here we've got developers and site builders, but this can extrapolate really even
more if you want to break it down into back-end developers and front-end developers. For developers, it's really about being reusable, consistent components. We can define props and slots in the component.yml file, apply styling and maintain a complete, clean library that aligns with whatever design system we might have been given. And it also ensures that they behave predictably across the site. Meanwhile, site builders, you we don't have
to wait for developers to adjust templates or write codes. We can just say, "Hey, we need to change to this component. The design's updated. Go in, manage display interface, and map the fields and slots to present whatever presentation mode view mode we're using." I think the real benefit here is that your teams can work simultaneously at the same time but on different things. So, we've got developers,
site builders, designers, and fed. We can all work independently but stay aligned. And overall, I've seen this speed up timelines and just made it more maintainable and more flexible sites. Here's kind of the recommendation I have if you're going to process it across your team. First, start by architecting your content, fields, and everything that's going to map into those components. Effectively ensuring that you have the right
structure kind of from the beginning. And then from there, have all your teams meet. I know it seems counterintuitive, but have your teams meet and just agree on what the data types are. Going back to how we built those components, remember Drupal's going to hold those approved props and slots as a contract. How it's going to work, what it's going to expect. And if we can just
get even if we don't have time to build that component right now, we can start styling it. Once the structure's been defined, you can split up the remaining tasks where developers can focus on needed component logic. site builders can start working on the actual content mapping, and designers and front-end developers can work on what those styles might translate or look like in that Uh when it comes
to styling specifically, I would actually suggest that front-end developers start with either placeholder content that you can map those data structures in, so you can just say, "All right, I'm passing in, you know, generic strings and whatnot." But that lets you style without waiting for anybody else. It also allows you to iterate quickly with design and show clients like, "Hey, is this really what you want it
to look like?" And maybe the answer's no. And you can go back and keep changing things while you're waiting for the back end or site builders to catch up. So, I've done that using a node with like static content um or a static content with the Twig file and using like a style guide if your site's using something like that. If you're looking where to start with
both SDC and SDC display, this is that resources slide I talked about. I recommend taking a look at these and I've shared the slides, so hopefully people have them. The first place I would suggest going to is the docs that we have listed on drupal.org. There's a ton of resources in there, a super detailed FAQ. If you want to see more added to that doc, please talk
to me because I will update it. Um I'm very happy to talk about docs. I know, not everyone is. And if you ever have more questions though that aren't answered by the documentation, that's where I would say our Drupal Slack channels are really good resource. We have both components, so that is literally just SDC components, and then the hashtag support. Both of those um I'm pretty active.
If you've got questions, you know, you can always ask about components. Happy to happy to do what we can. And I've also added a few links to the modules that we talked about. So, we've got SDC display. This is that link to SDC Devel where I was talking about that. And two others in here, and this is kind of where you if you want to take it
a step further, you can. I've got Prototype, which is a starter kit theme that I manage. we are entirely SDC based, but it may not necessarily be an approach that you like, so you know, take a look. And UI patterns. UI patterns is a very robust version. I mean, even more so than SDC display. It allows for a lot of that nuance that you maybe SDC display
is not going to be the exact answer for you. And maybe you need something that is more robust, it can handle more specific situations. I didn't cover it today, but it's a great module. They're currently listed as UI patterns and then in parentheses it's SDC display and Drupal UI. Phenomenal if you get a chance to look at it. We are finally at the end. Thank you guys
so much for listening. I'm going to leave this they've added a QR code for feedback if you have any on the presentation. Again, the slides are available and I've got a couple minutes here to answer any questions. Yes. Okay, so the question is how to pass data into a direct SDC component that can't necessarily use the view display It really depends on your data. That's you might
end up being in that situation where you're you're passing data either into a render array in PHP on the back end and there is a doc about how to do that on drupal.org. So, I know I showed only the include statement, but that is probably what it is. Otherwise, if you have a template that you can hook into or that you can create a version of, you
could try passing the include statement. I don't know that you'd be able to use SDC display specifically, and that might be where trying UI patterns might work Yeah, other questions? Yeah, when you're mapping the fields with SDC uh does it use the field templates in in that mapping does it render the field template before it passes it to the component? Uh because I noticed you were using
the field value module in the other Yeah, um I'm fairly certain it does. Uh I'm sorry, the question was does when you're rendering content using SDC display and you're mapping to fields, does it map including the like field template itself? And I'm fairly certain Yeah, question. Do you find increases the speed on the development team, like simplifying code reviews and things like that? So, the question is
do I find that it simplifies and speeds up the development team, simplifying code reviews and speeds up the development team. It really depends on your development team. So, I personally think it does because I can delegate when I'm working on projects. I'm very fed oriented, so I can say, "All right, let's start building out these components." I'm working with design, and I can have our back-end developers
building out and architecting the sites. I've seen that the benefit there is it allows me to iterate pretty quickly. Um in terms of PR and code review, I'm going doing code reviews, so I like to think it makes me faster. Um I think the hard thing, this is probably the hardest part about doing code reviews, is it's config. So, total transparency, SDC display puts all the the
lovely, you know, click click click in your config. So, instead of doing a code review where I'm like, "All right, include statement, lovely." Now it is let me read through this config. And honestly, I just load up the site. I'd rather look at it that way and then and it, and I go, "I trust your config is correct. yeah. Other questions? Yeah. when we look at the
the schema file, Yeah. uh my assumption is that's using JSON schema under the hood. Is that a correct assumption or is it a is it like a modification of JSON schema a little bit? That's a good question. I think it's using just JSON. I know you can actually go to the JSON file like the validation schema file in core and take a look at it. Um That
that URL >> Yes, this URL is in Where we got? Yeah, I see it up there. Yeah, it's in right now that one says SCC project raw. I don't know if they've updated the URL to read Drupal core yet or not um off the top of my head, but yeah, you can actually go and look at what the schema file is expecting in terms of validation, but
it's pretty much just standard. Another one, yes, lovely. Uh you mentioned that you'll if you use SAS in your components, uh you have the source file. I'm curious, where do you uh where do you have your package JSON if you have like four or five components? Are you putting a package JSON or are you putting your all your node dependencies in each component and not checking In
other words, how do you manage that build when you have multiple components? Okay. Yeah. Yeah, so the question is how do we manage using So, how I talked about having a source file with our SAS files, how do we manage that build when we have multiple components? So, the way I address that is in each component, it has its source file. We do have a package.json at
the root of our theme. And we're using You can use things like Rollup, which I think they're working on core V. Uh I think we're using Webpack for right now to manage it, but they compile each one and it makes sure that this The only thing that's really important with with using SAS in these components in that structure is that your CSS and your JavaScript files need
to be output inside that component's folder for the automatic library that I talked about to pick it up. So, that's that's what And we have it where it's just doing like a like a gulp command listening to all of the components, and if one changes, there's a dependency, we can say, "All right, it'll recompile that component." Or I can do recompile all of them. And the nice
thing there is it lets me change one component without necessarily like if I have to touch anything else, or I could change the text site-wide, and it will change it everywhere cuz we're using dynamic CSS variables. Or at least I like to. In terms of portability then, uh if you take if you cherry-pick one of those components and hand it off over here, whoever's going to consume
that has to have their own build process, right? Because the package.json isn't shipped with that component. Right. So, the follow-up question to that is then if we take that component and we put it on another site, is it using the same package components with like compiling? And the answer is yes. So, a lot of the same stuff I work on I mean, yes and you could just
grab the compiled files, the CSS, and and go on your merry way because effectively that should, you know, strip out most of the stuff that's in our Sass file anyways. Um but yes, the theme would need to I be using SDC, and it would need to be using supporting libraries in a similar format if you're going that route. Um the benefit for that is it's just made
it faster for us to iterate, and I don't the files I'm changing aren't committed. So, when we're working on the Sass files, the CSS files aren't committed. So, we're making a bunch of changes cuz we do an ignore on them so that we don't end up with merge conflicts constantly. And then we leverage build tools that render those components when we do our, you know, push to
GitHub or GitLab, etc. >> That does the final build then. Yes, that does the final build. >> Okay. Okay, great. I saw a question I know I saw a question. Yeah. I was just going to say >> Well, that's amazing. They just said that Drupal will compile Okay, Drupal will compile CSS similar to SAS. It's not exactly a one-to-one, but that's pretty nifty and I'm going to
go try that out. Um, excellent. I think I had saw a question. Yeah, I'm a pretty big So, the question was is there a performance difference that you see in this? And I think so in the sense that it's only going to load the libraries that you're using on that page. So, if you just have your global libraries and text, no component libraries are going to load
unless you tell it to. Um, you have only your slideshow on a certain page, only your slideshow is going to load. Honestly, it's been really impressive in the sense that I'm not having to either load global stylized libraries or I'm not having to load a bunch of things even though I'm not using it on every single page. Um, so, yeah, I'm pretty happy with that. Other I
think I've got like 5 minutes. Any other questions? Yeah, so the question is do we have a large global library that we're inheriting base styles from? So, I'm kind of opinionated on this and if you take a look at the prototype theme, um, hello, you'll see that. So, we actually have a couple of base, uh, styles that we are loading on every page and that is going
to be your themes, it's going to be your site-wide theming colors. It's going to be your dynamic font sizes, font like spacing and those are actually getting rendered as exposed CSS variables so I can use them and I don't have to worry about the SAS includes and things like that. Um but, we do use those just globally cuz they're kind of things that are happening on your
site anyways. Your buttons, your links, you know, your table styles. But yes, so we do use those and then I like to really style your components specific to the So, and if anyone has played around with Drupal 11.2 yet, I don't know if anyone has or three that just came out. Um SDC is starting to introduce variants, variations on components. So, inside components you can create variants.
Um I haven't put the docs together for that yet, so but it's there. So, if anyone wants to feel noble and test it out and tell me. Yeah, that'd be great. Um but yes, so that's that's kind of how we handle the libraries. Yes. It looked like in the uh in the include in your Twig file component the names have to be unique across all providers of
components. Is that true? The name of the component? >> So, card, could you have a module providing a card SDC and a theme providing a card SDC and then you have a clash or they name space? >> No, you can Yeah, so they're they're they're scoped to each individual uh the question was can you have the same name >> is the name of your theme. >> Exactly.
Can you have the same name as a component? And when I was searching in that video, I think, we actually saw I had two card components. It'll let it run. But, you can have two components named the same thing but it's the key in front of that. So, that's your theme or your module. In the example you saw it was prototype, but yeah, you can have the
same name. That's really where getting in with the readme files. I love that those render now. The um your description, so you know exactly what you're in. But, it can be annoying if you have like six card components, I'm just saying. So, you know, if you're feeling adventurous, name them something else. okay, one I think we've got time for maybe one or two more. Any other Yeah,
so somebody just asked a very fabulous question my designer's going to love. Um, have we used SDC display as a way to create design documentation? And no, but thank you. Uh, I'm going home with that one. Yeah, no, we haven't and I actually don't know why. I feel silly. Yeah, no, that's actually that's like a super awesome idea. Yeah. So, that's where the fixed value comes in.
So, it won't use So, the question was is there a way to use the examples in that component.yaml file, right? We were like super cool heading, amazing. Um, no, you can't necessarily right now tell it to use that, but that's where I would leverage that fixed value. So, if you're making a design system, for example, and you've got a component and you don't want to have to
go and create a million piece of the content, you can set where I had done like arrow right, you could say here's my static heading. Those fixed values are fallbacks. So, if there's no content passed the component, it's going to go and display that. So, I think that could be a really good use case for leveraging that. All right, I got 1 minute. Any other Oh, okay.
Hello, yes. >> Yeah, you're right. So, the statement was the SDC library, that's the module, right? Will allow you to add story.twig files and it will render those for you using that. So, that There you go. Every designer is going to hunt me down after Um so, that's another option we could use. I haven't played around with that though, so I'm going to I'm going to play
around with that after this. Okay, I think we're at time. I think it's 10:20. Thank you guys so much. I had a lot of fun. And if you haven't, I would really appreciate you scanning the QR code and telling me what you would like to learn, what you thought about Lick, and stuff like that. It's like a five-question
