 Today I'll talk about the simplifying structure in Drupal, how we can utilize the single directory component approach. Before looking into the technical stuff, I'll try to introduce myself. So I'm working with Salsa as a technical lead. I have around 14 years of experience and working from India remotely at Salsa. It's been six years and I have done great stuff at Salsa. And why I'm talking about the single directory component? Because I have faced so many issues with how to structure your theme. We have seen a multiple design system while working on a Drupal theme, like most popular is a pattern labs. There are other design system as well. If you talk about the Australian design system, there were one. And right now, if you saw the civic theme, it's the most popular one. So this is the thing, single directory component is one of the new thing in Drupal 10. So we'll look into this. So before going further, I'll try to ask him to introduce himself first. Hello. Can you guys hear me? So yeah, I'm really excited as well to present here. So I'm Amai Mudras. I'm working in Drupal from past 13 years. And I started from Drupal 6 and now working until Drupal 10 now. And currently working with Salsa Digital from past two and a half years or more. So back to go in. Thanks Amai. So today we have a small intro. We'll discuss what exactly the component. I know you all are aware about the components of the design system, but still I'll try to give my best. The challenges that we face while working on the Drupal theme development, it totally depends on the front end development. So you're not interested in any front end technologies or how you create a new front end. I think it will not, maybe it's not for you actually, I would say, we can explore some benefits of how you can use the STC. We'll look into the anatomy of the STC. We'll provide you some example or implementation so you can look out after this. And a quick term of follow up with the questions answers. So first thing, I'll go with the component. So let's start talk about the component. So if you're going to compose a UI, if you want to build a new UI in your theme, what exactly first thing in your mind, how exactly you want to create it. So I would suggest like, if you talk about this particular layout, you've seen this, you can see some of the text, some of the button, form elements and the bread crumb. So anything can be a component. If you talk about the atomic design, we use the smallest element as a component, then we will, like as a Lego blocks, you can build, connect them together and create a new layout. So in my simple terms, a component or self-contained unit of code that encapsulates the specifics of functionality or user element interface. So by using the component, the good thing is you can reuse them anywhere in your project. It doesn't matter how small it is, but if you want to create a layout or a consistent page with the different set of components, you can use them. So I'm not going into the deep in the components because it's another theory. So let's talk about the challenges and triple theme. I'm sure you always, you also have some challenges in triple theme. What do you think? How it will work? What the first thing you will think about if you're going to create a new theme? How your UI will look like? And what can be a component? So how exactly you can start? So in triple front-end challenges, when I came across a few of the things, so all the assets in a theme are scattered across the different folders. If you talk about, if you want to add a new JS, there's a JS folder. If you want to add a quick template, there could be another folder or there could be an asset folder where you put your trick file. And if you want to add a new CSS, you will have to add another CSS file. Then after you can provide some business logic on top of that. So in ruple theming, we have a multiple way to create a business logic using the theme. Like there's a pre-process available where you will pre-process all the fields and all, then you will create a new component. So it's really challenging in case of how you maintain your triple theme, because you don't know where exactly your component, because it is loading one JS file from another folder, one CSS from some other place. And then you have to define your own library if you want to separate that particular component in a page. So I already discussed this, so what is single directory component? As the name mentioned, it's a single directory. So if you talk about Drupal module theme in a module, module have a single directory where all the functionality is encapsulated in a single. In single directory component, its first thing is it's in Drupal code. So you don't need any additional module if you want to create a single directory component. It's a new way that you can implement components. How you can do it? Just create a new folder in your theme or in your module, but your template, CSS, JS, you don't need to define the libraries. It will automatically load everything. So this is how the structure will look like of a single directory component. You will have a trick file, CSS file, JS file, it's any other assets you want in that component you can add. So all the dependencies, everything is managed in a single directory only. You don't need to define your JS, your library on any other place. Drupal will automatically recognize what exactly is the component and it will automatically load on the particular page. So now look into how this will solve your problem. I don't, I talk a bit about the benefits, but still the hooks, the most important thing, if you are in a Drupal theme or developer, you have to be aware about the hooks, how you pre-process your fields, your data, if you want to embed your trip file, there could be multiple pre-process that you need to write before looking into what is the final outcome. If you are not a Drupal developer, I don't think so. You have contacts, how the fields will render and how you can get all the variables required for your data. So we are trying to organize the frontend development using the single directory component because in single directory component, you don't need to have a good context about Drupal. It's as simple as that. You can create your trip file. If you are a UI developer, you can easily create your trip file, provide the slot, properties, variables, whatever you want and all the CSS. You can use the SAS and other things as well and you can use different like WAP pack, anything to build those inside the component only. So it's a new approach. It's also efficient in loading because as I mentioned, it's a component. So it on demand, whenever you embed this trip file in a particular base, it will load that component only. It will not load whole CSS or CSS across your Drupal project. So it's a new theming approach and the integration is very simple because you don't need a module. It's in code. So I would say it's provided you the improved performance in your project if you are using the component-based design. If you already have a design system or something like that, you can create your different kind of component inside your module or theme and if you want to organize your code in a better way, I would suggest as DC will the good thing. Before going further, I'll talk a bit more about the benefits. I know I already talked about them but still there are a few things that these are the few points that you can see on my screen. How you do the organization, how it is provided the consistency because if you have the coding structure style across all components same and if you want to update any component, you just need to look into the single directory. You don't need to look all over the place where is my CSS, where is my CSS. Nothing like that. It's modularity reusable because it's a component. As I mentioned in a component-based design, we are nesting, we are building blocks so you can add one component to another component, reuse them across the project. So it also scale in a many way. So if you talk about the atomic design system, you can have atoms, molecules, organs and the layout. So in the same way, it can scale in any way. It's easy to maintain and the other thing is automatic library creation that I mentioned earlier. You don't need to define the library. So how exactly the JS and CSS will load automatically because as DC, it's part of code. So it will automatically recognize and load all the library. So you don't need to define your library again and again in a theme or in a module. It will work. The good thing is it's really easy to find. Just find your folder, delete it if you don't want it. You don't need to go into JS, update your code and clean up. It's it. So I'll hand out to Amir to proceed further. And thanks. Thanks Govind. Thank you for making us understand the benefits of SDC. So let me take you through the technical side of it and let me start with anatomy of the SDC, single directory components. Let me start with the structure. So first things first, we need to create a components. So in order to define a component, you need to create a components directory either in your theme or in your module. This directory holds all your components. So you can have multiple components added. This components can be nested. So it is not needed. A theme can have multiple components and also nested. So for example, if you want to have atomic design, so you have to segregate into atoms, molecules, et cetera. So you can do that easily. Then there is something called as a metadata file, which is like the heart of a component, which defines what exactly your component does, what other inputs input it takes and so on. So we'll talk about it in the future like in some slides. So there are two things, two files which are really required for a component to be identified by Drupal. First thing is component.yml. This is the metadata file. And second is the component.wig. This is the file which does take care of the output. So let's look at the directory structure. So I've taken an example of Olivero theme. I've created, if you see components directory, this component directory now houses like multiple components like banner, button, cards, et cetera. If you look closely at the structure of cards component, you'll see assets which are grouped. And I have a card.component.yml. This is the metadata file I was talking about. Then there's a Twig file, then there's CSS file and there is a JS file. So let's look at each of these in detail and understand how to implement a component in case you're using HTC. For this, let's take an example of a card component which we generally use in our pages. So this is one of the card components from the salsa digital page. I've just taken an example from there. So we have an image. We have a title in the description as you can see. So let's see how we can build this component now. Okay. Let's talk about the metadata file in detail. So in order to define a component and for Drupal to identify a directory to be a component, you need to define the component.yml. It needs some basic details like schema for your ID to recognize. It requires your name, like the machine name and the status. So this is the very basic definition of a component. If you see next, you see schema properties. So these are any inputs that you provide to your components. So for example, in our case, if you had seen the previous slide, there was an image, title and description. So all of these will be properties. So properties follow JSON schema. If you look closely, we have the type definition. Then we have title, description and some examples as well. So look closely. It's quite simple to define a component. If you see, it's very easy to define a component in that way. Next up, there are slots. Slots are also inputs that go into your component. But only difference here is that the type of input is not defined. So we take it as a slot. And in terms of properties, any type, like wherein you can define a type, it can go in as a property, whereas slot does not have a fixed type. So any HTML, for example, can go into your slots and any fixed properties like integer, string can go into the properties. Next up. So before going to library override, so if you have an asset, for example, if you have a component, so card, for example, that we have taken, the CSS, JS files, whichever, for example, card.css and card.js files will automatically get loaded. So if you have used Drupal theming, you would have generally what you would do is you would define a library and add your JS, CSS files. In this case, you don't have to do it. It gets loaded automatically. But in case you need more JS files or more CSS files and you need more dependencies, in that case, you can use something called as library override. So this is an example of it. Next up, let's see. So what if there is a component which is already present and you need to override it? How do you do that? There is a division for that as well. So if you look closely, there is a replaces key. So in the replaces key, you can just add a component name which is already present. So for example, if Olivero theme is already providing a card component and if you want to override it, you can do that. You just need to put in the theme name and then your component name which you need to override and also fork that particular component Also, one more thing to keep note is the schema properties and slots must match. So that's the only one thing. And another thing that I missed out is only themes, only components provided by themes can be overwritten. So yeah, that's about the metadata. Hope you guys have understood the basics. But let me point you to an example which is there on Drupal.org. Drupal.org provides a detailed example of all the properties which are available. So you can see, I'm not sure if you can, but you can have a look in the future. I'll just guide you what exactly this provides. So it provides you all the properties which are present. For example, name, statuses and there's a detailed explanation given over here. So what exactly is properties and what are slots and how do you add more dependencies so everything has been provided over here. Hope I was able to cover the basics of metadata. So now let's look at... Now that we have defined a metadata, how do we use the properties or the slots that we have defined? So for that, you can use it... Yeah, I'm sharing the correct screen now. So now that you have defined the slots and how do you utilize these properties? So for that, in the tweak file, you can make use of the variables like how you can see... So the properties... Just like how you use any other variables and the data will be passed on to the tweak file. So that seems pretty easy, right? So next up, now you have made a component. So how do you utilize that? And once you have defined... So there are two ways of doing it. First one is using tweak templates. So in your tweak templates, you can use include command or embed command and just pass the name of the component and whatever properties you have defined. So you can directly pass those. The second method of doing it is or just like how you used render arrays from Drupal 7.8. Just define it as a render array and then you can render it later on. So hope this concept is clear. At least the basics are clear and you know how to build a component. Let's look at the next section which is regarding component libraries module. This is just an extension module which is available on Drupal.org a component library generator. So what it does is it generates a component for you on the fly and it will ask you multiple questions. I'll give you a detailed demo on that as well. Okay, so this is an external module. So you can just download this module using... Sorry, you can just download this module and you can use the command Drush Generate SDC and it will ask you multiple questions regarding what kind of a component that you are trying to build. Let's see that in a detailed example. Okay, so yeah, I have recorded this video so that I don't... I save on time. So I have run this Drush command as you can see. It first asks you your team name where you want this component to be created. So in my case, it is Drupal South. So the D South theme I have created. So once I've added it, it asks me what is the component name. So I'm trying to create a map component here. So then it'll ask you a series of questions like machine name and what description you want to provide, etc. What are the library dependencies you want to give? Do you want CSS along with it and JS files along with it? So once this is done, it will ask you whether you need properties or not. So if you want properties, you can say yes. Then you define properties. In our case, say for example, you want a map title and you want, say, map description and height and width. So these are the four things, four properties that I'm trying to utilize. So it will ask you series of questions regarding what type this property is going to be, what is the description, etc. So here... So what we are doing is adding multiple properties. Similarly, we can also define slots. So height, as you can see. Hope this is... You are able to view it correctly. Hope it is... Is it too small? Oh, sorry. Let me try to zoom in. So if this is small, maybe you can give it a try. It's a very simple module. You can just install the module and just run this. It's a very basic prompt. So let me explain what exactly it will ask you multiple questions, what theme it is, if you need properties and what details about the properties. Once you... All this is done, you will get details of the newly created component, as you can see. Now let's look at... Let's look at the component. It has created a component now. So as you can see, map.component is visible. It has added multiple properties that we had mentioned. It has defined the type for each of those. As you can see. And you can then utilize this further on and you can build up on it. So this is the map.tweak it has created. It has created map CSS files along. So it gives you a very good starting point to build up. So let's look at another example. Let's see a component which is already present in any of the themes. So I have made use of umami theme which is already present. So let's look at the disclaimer. How it renders. So they have defined two properties disclaimer as string and copyright as string. And they have also provided an example of how the input should be. Yes. So this is how it looks in like real reality on the page. If you see the structure here. So this is how it renders. Let's go back and check how exactly it... how exactly this is called in the first place. So if I search for disclaimer. It's embedded inside if you see. We've used embed command and it's used inside the block which takes two inputs and finally this component. So hope I was like able to give you a starting point and I could explain you how exactly the component is built and how exactly what exactly SDC is. So yeah. Here are some resources additional resources you can have a look at. The first one is the one which I already showed you the annotated example. The next one is the components example module which is already there on Drupal.org. They have explained how exactly a component can be built in detail so you can have a look at that and there are a couple of more examples I have provided as well. More resources and if you are interested in like some development work then you can also join Cache Components channel on Drupal Slack. Any Q and E? Any questions please? Thanks for listening. Hey, is it possible I noticed you had on the props example text of how it gets used is there some way like say I'm a front-end developer and I built some component can I test that component without a Drupal installation like I just run some JavaScript library and just pop it up and start? Without a Drupal installation it would be slightly difficult maybe you may know it's slightly difficult I feel because what happens is with Drupal the CSS.js file get automatically embedded so this happens at run time so I'm not sure how you can do it without. But the other part is you might use a storybook to render these kind of components. You can use those stuff and you can look and feel of your component. You went through the benefits there like not necessarily the negatives but what are some things that you need to consider I guess before making that switch to a single design? Before making switch to SDC. Sorry, come again. I said you went through the benefits there like I don't want to list the negatives but what are some things that you need to take into consideration before making this switch to a single component? I'm not sure. Before the front end development because as Joshua asked about how exactly you can create a component without using the Drupal so this is how you can do it and then after you can utilize those CSS.js directly in Drupal. You don't need to have the context of Drupal to create a component itself. That's the good part actually. I just want to add can you hear me? I just want to add to this. Downsides as in there are very few I can't really think of one at the moment but the thing is once you've structured everything you'll have to maintain it so that's the only thing I can say. Thanks guys, great talk. From the sounds of it, if it's just been released in Drupal 10.1 this is quite a recent feature. Is there still more work to come or more things that's going to be released around SDC? For now a lot of modules and themes are using it so I'm sure there will be advancements but the roadmap currently is to build up on the project side of it a lot of get-get adaptation to it so that's the current roadmap. How this is going to be improved in future so that's something which we'll have to look at the current roadmap is to get more and more adaptation so there have been talks for multiple modules known modules and themes to use this so as I mentioned Umami already uses it so there will be more themes and modules coming up. Sorry, no question. You had PHP files as one of the files for the component Yeah, yeah. Does it execute included straight away or do you have to put some function for the PHP file to execute? It executes functions. You can use some method functions basically. How does the function get called? I did not explore it, sorry. Does the function follow some pre-process like it will match some pattern and it will get called? Sorry, I don't have an answer to that. I did a PHP file but I'll come back to you on that one. The pre-process is not required. Pre-process and hooks don't work so it's like everything happens before you call a component so once you have called a component it follows whatever end-of-path is there. Real nice stuff to talk guys. Thank you. I just have one question migrating from the ongoing system 10.0 is there a command for that or a module to do it automatically for me? Currently no. Themes, whatever components there could be render logic everywhere. In the current context it could be everywhere there will be hooks, there will be pre-processes etc. That you will have to do it on your own but it's fairly simple to migrate if you are doing a component. It's a different set of front layer you can implement altogether in a different system. Even with the Drupal 9 you can use a contract module before it was a contract module available but in 10.1 it's in code so if you are using the Drupal 10.1 later you can directly use it other than that. If you are in Drupal 9 there is a module available so still you can use it on Drupal 9.