 As you can see, this is the best session of the DrupalCon. Yes, yes. I don't know who can say that. It's factually correct, so I think it's legal. Okay. All right. I'm Mateo. I did work on getting JSON API into core. Recently, single directory components, and I work for the school company, Lullabot, and we are employee-owned, and actually all of the work that I did for single directory component was sponsored by Lullabot. We have some internal time, and if you're curious on how we sponsor Drupal Development, we recently wrote a blog post, and it's in our newly redesigned website, so go take a look. So my name is Mike Herschel. I have done a lot of Drupal Core stuff also. I worked on the Olivera theme and several other cool things. Most recently, I kind of cheer-leaded, I feel, to get Mateo to write most of the code for SDC. But I work for Agilina, which is an amazing company that I am brand new with. We are hiring, so if anyone is looking for any positions, you can come talk to me. You can see my website, social media, and all that good stuff right there. So Mike and I are here doing the presentation, but others helped, and most notably, Lowry and Christina, they joined forces from the beginning, providing help on figuring out what are the features that we want to include, making sure that we paid attention to developers new to Drupal, as well, and that they were included and helped as part of this, of the work that we did. Here is the maintainer of the UI suite modules. If you don't know the UI patterns, go check it out. It's pretty cool, and they've been working on many implementations of components in real life. So validation from their team was really helpful for us to make sure that we were delivering into core the best possible solution. And along those lines, Alex Pot and Lee Rowland, core committers, they were providing a lot of helpful feedback in the code that we wrote, and they helped making the best code base that we could have put into core. So thank you to all of those. So let's talk about what we're going to talk about, right? So we're going to talk about what we're fixing. What's the problem here? We're going to discuss how SDC works. I'm going to do this session of coding karaoke where I have a video where I'm actually converting a component to use SDC, and I'm going to narrate that for you. We're going to talk about how modules and themes can extend SDC and degrade into things like storybook and fractal, and then what's the future, and the future is super, super exciting. So before we get started, who here is a front-end developer? Who here has done any type of, tried to do any type of component stuff in Drupal? Who here has felt pain? So components in Drupal can be a pain in the ass, right? But no longer. So the problem that we're fixing right here is where is your CSS and JavaScript coming from? That's really difficult to figure out unless you have been in a Drupal ecosystem and you realize how that works. If you're coming in from outside, everything's new, and it's a little bit difficult. So let's figure out where the assets are located is difficult. The files that you're working with together are scattered across the file system, and it's really, really easy to lose context. We don't know what data is expected into a component and what data is mandatory for a component. And just locating your template can be difficult at times. Right, so here be patient with me. I'm a backend developer. I'm going to speak about UI. But in my research when trying to build a system so front-end developers could work easily with components, I realized that components are more of a way of putting UIs together, and one defines a component as they need. Like a component is what you want a component to be. So there is no wrong way of saying this is a component, and you usually do that and put it in a semantic way so things that make sense together into composing your UIs. And typically in practice what that means is some template and some styles and some JavaScript, and together you make like a rubber stamp that you stamp all over your site. With the added benefit that you get input to your components like those rubber stamps that you have a dial for the date so you can change it every time that you stamp it. Right, and we couldn't find any other tech stack that was not using components. Like everyone was having this huge component party and Drupal was not invited to the party. So, like Mike said, I was working on this problem space and I asked Mike if we could do what we do best and we achieved making Drupal crash the component party. We took Drupal and we made it so you can add components easily and what that looks like in practice is it's called single directory components so it's just a directory inside of your components folder. Your components folder leaves out the root of any module or theme so you can provide components as part of your modules and as part of your themes. This directory contains JavaScript, CSS, and Twig template and it also needs to contain some metadata and that is how we will discover the component and you can optionally contain documentation about your component that will be very useful for all the people that are using your component and also can contain thumbnail and other stuff but these four are kind of the important files that a component contains. And one of the later focus goals that we had is that everything has to be in that directory. There are no hooks. You cannot alter a component from another module because that other module is not in your directory and you cannot do anything else to your component that's outside of that directory. So the benefit of that is that when you are editing your components you know where to go and you know where to find everything that's affecting that particular piece of your website and also as they say, good code is easy to delete. I don't know if you ever tried to refactor some CSS. I tried, I'm a backend developer and I'm always afraid that that CSS may be used elsewhere and I just... Me too, Mateo. Me too. See? So with components in that style only applies to that particular component you know that you can refactor it and you can delete it if you need. This is a bad slide. But bear with me. This is just for the video. If you want to revisit this and pause here and understand a little bit better but just pay attention to the start and finish. We will start with include and then the name of your component the ID of your component and that will produce some HTML and JavaScript and CSS and that will happen in these two step process, these dashed boxes. One is to find the plugin, the component where that metadata file that I talked about and the other step will just pass it to Twig and it will take that CSS and JavaScript to create a library for you so you don't have to go and create a library anymore because this step will do it for you and it will also attach it to the page so you don't have to attach the library to the page anymore, right? All of that happens automatically. So you use include and embed from Twig and you get HTML in result. What if I use your mic? So I am doing this, I have this video that is me coding and I'm going to narrate it as I'm switching over component. One of the things that I want to point out with this video is that when I did this initially it took me over an hour to do it so I'm going to do this in 10 minutes, I'm going to go pretty fast but the URL with the full narration is at the bottom and so within the Canvas slide deck there's a slide where we have all our resources I'll give you, we'll switch to that too. So unlike regular karaoke, this is coding karaoke and unlike regular karaoke I'm very sober so let's see if we can do this. So this is the Florida Drupal Camp website Florida Drupal Camp of course is coming up next year in mid-February. We're going to look at last year's schedule and the schedule items that you're seeing right here we're going to refactor this into using a single directory component so this schedule item is a details element it has a lot of data including title it has those contextual links, etc. So let's get started right here the first thing we're going to do and you should be pretty familiar with this step is we're just going to disable CSS and JavaScript aggregation this is regular stuff right here but what's new to Drupal 10.1 is you can now turn on twig development mode and disable caching through the UI now you can still do this through your settings.php and development.services.yaml so when we look at this right here we can see this is a regular component this is the no-session-teaser.html.twig so this is our kind of starting point this is what we're converting right here so the first thing that we need to do is we need to enable the single directory components module this is just like normal there's no configuration keep in mind that once SDC becomes stable it's not going to be a module anymore it's just going to be turned on all the time so I only have to do this while we're experimental next we're going to install Drupal Core Dev this is not mandatory but what it does is it lets the SDC module output really really really helpful error messages and you're going to see these later because I'm going to intentionally show you some of that so this is our starting point right here this is our no-session-teaser.html.twig the first thing we're going to do is we're going to create a directory called components this is where all your components are going to live and then for each component you create a new directory we're going to call our component details and we're going to have two files in here details.components.yaml and details.twig and we're going to move some other files in there in a second for the yaml file we're going to go to our documentation that we spent a lot of work on and we have this example components.yaml file and this is going to be our starting point so I'm going to copy and paste this in here I'm just going to start deleting all the stuff I don't need we're going to call this details and we're not doing any replacement we are going to have a schema in this and so I'm basically just deleting stuff but I want to know what the syntax is because who can ever remember that we are going to do a couple slots so I'm going to have a placeholder there and we're not doing any library overrides you're going to learn more about all that other stuff later next we're going to copy in the sas file and the css file and after we do that we have to rename them so we're renaming those in the name of the component so that's details.css and details.scss and of course we have to update our scss to point to wherever it's pulling its variables from so this is our starting point right here so let's start building that schema but before we do that we have to copy the html from the no-session-tizer and paste it into the new details.twig and so let's kind of put everything side by side right here and so our first variable that we're going to pass in is the attributes variable and we don't quite know what this is yet I know it's a Drupal class and I'm going to show you later how to figure that out so the next thing that we're pulling in is we're pulling in this classes array so this is a type array and all this type of stuff is in the documentation by the way label is the title so that's just a string we have two booleans in here is non-session and is training so we're adding those and then we're pulling in the big content and that's an object because it's an associative array and if you get that wrong SDC will give you error messages that's really helpful so URL is a string then title suffixes and an array so the next thing we're going to do is we're going to delete the code the markup out of the no-session-st and we're going to create a twig embed and the format for this is the name of the theme or module where the component resides colon and then the name of the component we're going to pass in all of our variables or props or whatever you want to call them and so at this point we're going to create a twig block now a twig block is the same as a slot so we're going to call this block meta because it's metadata I'm going to paste this in here and make it look pretty and then of course we have to add the placeholder for that twig block within the details.twig and we're going to do the same thing for the description right here now I don't necessarily have to create these twig blocks but I know for the Florida Drupal Camp website that I have multiple content types using the same component so I want these twig blocks in this case so I'm going to do a little cleanup right here I'm going to get rid of these set tags and just kind of put those into the twig embed right here I don't need to do this but it's just a little bit of cleanup and it's looking pretty good right here so we're going to clear cache and we're going to see if it works so let's refresh and of course we have our favorite screen ever but if you look at the error message the error message is super useful it says string value found but a boolean or an object is required and it says the fields so what that means is that these isn't on session and is training fields are actually passing in strings so we're going to use twig ternary operators and force it to pass in boolean so let's refresh one more time and see if it works and it's working so let's look at this it's awesome alright so we know we're getting pretty far here we're pretty close but we still don't have the attributes there and we also forgot to do our slots so I'm going to create the slots right here and I have description of course I have to make sure my indentation is proper and now like let's figure out how do we figure out this attributes right here so within Drupal 9.5 and later the dump function is basically a wrapper for for a symphony var dumper so I'm going to dump the attributes and that's going to output on the screen right here and you can see right there it says Drupal core template attribute that's a class so we're going to copy and paste that into the metadata right there and after that we're going to uncomment this I should have cleared caster but I totally forgot but let's check to see if it works and we can see everything is still working good so like yay so there's a couple other things we want to do we want to use the only keyword and the only keyword will ensure that no additional variables, context, or anything else is being passed except for what we explicitly pass and then we double check to make sure it's working but it's not quite right if you look at that we're pulling in an SVG from outside and so I don't want that everything needs to be included into components so I created an image directory and then I'm fumbling you can see this I'm fumbling around looking for this SVG right here it takes me like a second which reinforces the point where it's hard to find things in Drupal so I finally find that and I put it in here right so the next thing I need to do is how do I reference the path where I am how do I get that file system right and so I'm going to use the dump function again I'm not going to pass in any parameters and when I look at this I see at the bottom right here I see an array with component metadata that is the SDC module creates this and so I do a couple things wrong here by the way so the first thing I needed to use a key inside of that you can see you can watch me troubleshoot I'm also in the case right here I'm converting the include tag to an include function which is best practice because at some point the include tags are going to be deprecated so I'm trying to figure this out right now and I don't realize that I actually have an enclosed parenthesis because everybody does that right so I'm figuring that out and then I realize alright well it's not just component metadata I actually need to figure out what's inside of that and you can see the path key at the top tells me where this is located so what I need to do right here is I need to put component metadata that path is it going to work no it's not going to work because I still have like I got my directory wrong so I need to update my directory it's img.images and now it's working so yay like you can see this little svg that we were wrestling with right there and we're not quite done yet we have to update our css so like normally this would be done in the sass but I don't have my gulp file updated but anyway so I copy the image in and then I just update the css to use relative paths I double check to make sure it's working and you can kind of see it is that little pdf icon and there's a couple more things that we still need to do we need to declare what is required here so in this particular case our classes are required our label is required and our content is required so let's just declare that a couple other cleanup items we can now delete this session teaser library that I previously created it's no longer needed because sdc automatically creates that for us when we look at this in dev tools here we can see it says component start you see it says component start the theme name and then the component name and it gives you that handy dandy emoji that emoji is randomly generated and it's really useful because it gives you that visual indicator and it's really useful if you have nested components which is going to be a frequent use case so this is where we're ending up right here this is our details.component.emo and you can see it describes exactly what is expected what is required and that's very very useful right there if you go to the no-dash-session-dash-teaser you can see how the data is passed to that and it's very clear what happens and then when we switch over to the details.twig at this point all we have is we have the markup and then we have the placeholders for all your data and it's pretty straight forward so that is it right there and I know I went really really fast but this is going to be up on youtube so y'all can like slow down a bit and shut up that was pretty impressive Mike. I practiced a lot and you revealed that this was always a very contrived way of getting emojis into triple core so let's talk about metadata because that's probably the stuff that seems more foreign to everyone so the good news is that none of it is required so you just pass it on and SDC will be happy with you that's true if you're defining your component in your themes not true if you're defining it in your modules you will need to define the metadata but it is highly encouraged that you define the metadata so let's keep evolving this first you can start defining a human readable name description so others know what your component does and then the status of the component if it's stable if it's experimental obsolete or deprecated and then the MIDI stuff starts right you thank you you should start defining your inputs the inputs of your component not your inputs the inputs of your component and that is done using a spec called JSON schema you saw in Mike's video that he was just providing the type so that's valid you just provide the type if it's a string or whatever in this example I'm going a little bit further I'm giving it a title description for the input in this case the think component takes an input called mail and it also provides format for it so if you in your development machine you provide some string which is valid but it's not in an email format it will complain it will throw an error message not in production but in your machine it will throw an error message saying well you're not mapping an email field right so that's that's useful and there are other constraints and validations like minimum length and there's a lot of stuff you can do in JSON schema you are not supposed to know everything that's in there but if you're curious on the stuff that you can do go to json.schema.org and you'll learn more about what you can do and what you cannot do and another thing that we had to do for the Drupal integration is extend the JSON schema to allow passing PHP objects because that's something that we pass to our tweak and it's not serializable into JSON so you can also pass the name of a class so that's custom to Drupal so that's the most difficult part of the presentation so if you got that it's impressive then slots are a little bit simpler you just declare the machine name of the slot in this case body but you can give it also a title description and you can say if it's required or not in the example Mike was just passing an empty object that's fine too and finally while we said that single directory components will generate a library for you for your CSS and JavaScript sometimes you will need to tweak it right sometimes you will need to add an attribute for a JavaScript file or add additional JavaScript files and I realized this is the version that we did an update so this should say JavaScript in there and you can also add dependencies like if your JavaScript depends on Drupal once then you can declare it here so basically you add this key library override and everything that you would write in your libraries YAML you can put in here to override what the automatic library will provide but you probably won't use this very often right so if you're overwhelmed which would be understandable because this is probably new to everyone here go to the annotated example there's like it explains every option and what it does and it has comments and maybe you want to follow what Mike did there and copy it and just paste it in your metadata one last thing that is special about the metadata is that we are aiming for components to also become the building block for theme compatibility I don't know if you know this but there's this base theme classy in Drupal core and it was developed a very long time ago and then it got frozen in time because many other themes started depending on classy and everything in there became an API so we cannot change a single HTML class or tag because then we break so many sites right so that is a problem and we want to address that for core and for contributor themes so by doing components we also aim to make these components become the compatibility layer for themes so moving forward we want themes to say here's the list of my components anything inside of the components may change at any time but here are my inputs and I will maintain compatibility of those so this is how you use it and when you're extending that theme you can replace components and how you replace components is by adding this replace key into your component so you take the component you copy that directory so components are copy and pasteable if that's a word you put it inside of your theme and you add this replace key so what that will do is let's imagine that there is this thing component that prints a yellow puzzle piece and you want it blue right so you replace it you copy the component you paste it in your theme and then you tweak it you just forked it right and to do that there are a couple requirements the original component needs to have metadata so it's optional but if you want it to be replaceable you need to add the metadata because let's imagine that a module provides a component and you are using that component but also a third-party module uses that component so the inputs need to be compatible so we're checking that and that's why everyone needs to declare the metadata there and then since you're forking it you are maintaining it from that point moving forward and you have full control on it so this puzzle piece I decided should be blue you could make it blink and shoot lasers like really you can do anything right and again you can only replace components inside of a theme because when you're replacing it you are changing how it presents right and you do that through themes so all that's done that's bundled inside a core and it's being committed and you can start using it now if you're using 10.1 which you are I'm sure but we are not stopping here we have more we have a broader vision on what to do with components right but the first thing that we need is help from you from module maintainers and theme maintainers to start shipping components we want components to become mainstream and boring and something that it feels like we've been doing forever so when components reach to everyone they bootstrap the innovation of cool modules that do stuff with components right they learn about your components using the metadata that we talked about and they do some other stuff like for instance something that we want to do is to turn components into a site building tool right imagine that instead of going to your theme and writing the template for your field you could go to the manage display tab and say my label field and then select the component that you want to render it with and then say well use the heading component for this field for this other field for the tag field use the peel component right so that's a good way of applying the components that may come from a base theme or that you are developing to use them inside of your site another good way of using components of the site building tool could be maybe in layout builder you drag your component into the page and you put your card in there and maybe even go further and you have a wheezy week button where you click it and you have a component pop up and since you are describing your inputs you can generate a form automatically for that so the site builder can type whatever they want for that button in there a like button another goal that we have is that we want to make components the most enjoyable way of writing interfaces in truple so we want to leverage existing tools like storybook the javascript folks have been using for a long time like life reloading they type in some css and they see change that instant feedback that the developer has in their local machine we are now able to access those and we want to leverage and integrate with existing tools and most importantly we don't want to maintain it we can just use storybook or other tools let me switch back to the canvas slide to see if that is working any better because we have a couple slides at the end that I think would be useful so first of all this is one that would be good to take a picture of if you are going to take a picture we have all the URLs up here and we spent a lot of time on the documentation the documentation is on truple.org of course we have an art guide which you can just copy and paste code we have of course the annotated example annotated component YAML we are working on an FAQ and we just have a lot of the details in there you can see my youtube narration right there please like and subscribe we are in the components channel in Drupal Slack and we have an SDC examples module that just has a bunch of examples in there so we need your help we are going to be sprinting tomorrow we are going to try to be converting core components over to SDC now we can't get these committed until SDC becomes stable which we are hoping to get done for 10.2 but we want people to get used to this and get working on it because it is really really cool we can't be the only people out here doing it go to your Drupal camps and talk about it maybe there will be a tutorial on Drupal or something like that Joe and join us in Slack and if you have questions reach out and ask us so yeah thank you and ta-da and we will take questions go ahead yes oh yeah the answer is the question yes or no and the answer is yes now the answer you ask if you find us tomorrow in the contrib room and you find us we will find something for you to do something to convert and we will help you out so we have several focus areas for contribution and one of those is writing components and then reporting how that felt right and then we will reveal some stuff on making it stable other areas are like writing documentation or reading the documentation that we wrote and improving it because we deeply believe that documentation can lower the barrier of entry for other developers and like we are not good people to write the documentation because we wrote the stuff and we know how it works right so if you come and want to help we will find ways yes so the question is can you explain how this will work with CL components and CL server and some people may not know what these are CL components is the initial implementation of SDC in core so I was happy at leaving it as a contrib but then Mike approached me and was like we should get this into core and I was like get out of here and then he started convincing me and now I was trying to find a nicer way so CL components is probably going to stay like it is it works for many people it has more than 7000 installed at this point and it has evolved into SDC but the surrounding ecosystem of modules like CL server they have version 2 and those are compatible with SDC in core so they are very similar there are some subtle differences between CL components and single directory components so migration hopefully will be easy if you want to do it or you are happy with how they are than you can say so the question is I am not sure I understand the question can you say that again so the question is is there any backwards compatibility issues when we have SDC enabled will regular twig theming continue to work as twig theming wants to work and the answer is yes, SDC is optional SDC is completely optional you have to there is a module but eventually it will just be in core but then you have to do your twig include and twig embed if you don't do that it will just work like normal it will work as is I think that is a Dave Reed module right we have to repeat the question the question is I saw that SDC is in Drupal 10.1 in core but I saw also a contrib module that has compatibility with Drupal 9 and the background on that is that when I forked CL components to become what we wanted to put into core I created that laboratory module called SDC so it matches what it is currently inside of core but there are some subtle differences to make it compatible with Drupal 9 so there are like different branches I believe that in the project page it says which branch you need to install depending on your version of Drupal a co-worker Dave Reed maintains the Drupal 9 backboard and I think it works yes so the question is SDC is in core but there also it says this other way rather popular called UI patterns and UI patterns allows you to do so many other features like integration with views display modes, it lets you pre-process stuff do things outside of the directory and how is that compatible if it is or how they play together we talked a lot with the maintenance of the UI pattern module and our hope was that they could just base their modules, their suite of modules on top of single directory components so what they will do and I'm speaking us of last week their plan is to remove a significant part of their code because now SDC takes that place and build on top of that so we everything in UI suite will keep on working as it has been working but they will now depend or build on top of what's in core so the question is what if you have some javascript and css that you want to reuse along many different components so what I would do is I would create a library just as normal right now and then within those components that you need to depend on that library you include that library override key and declare your dependency there does that make sense? there's a library overrides key so you can see this right here so library overrides allows you to override the automatically generated library and so single directory components will automatically generate a library and that library it will look for a component .css a component .js and if it sees those it will include those in a library and automatically make that for you now obviously you might have multiple javascript files or you might need to declare dependencies in that case within your metadata file you declare your library overrides and then the syntax is very similar to what's in your libraries your themes libraries.yaml file does that make sense? yeah cool work yeah that's a good question so will this work in like a nested directory tree like say you're using atomic design you might have your components directory then an atoms directory and then your components and the answer is yes you can create any type of arbitrary nested you know directory structure and it'll scan all those and look for them and find them go ahead so the question is when you're extending a component and when you're overriding a component you need to copy the whole thing and the answer is you need to copy the whole thing and some of the reason for that is that without copying the whole thing you would then need to look in two places to find how the end result is rendering right and we don't allow that yeah yes no, exactly but you need to copy and fork everything and from that point on you need to copy and fork of the component so there is no inheritance it's just replacement so the question is once we start seeing components coming through from different modules, different themes is there a centralized place where you can make sense of everything that your site has and the answer is that not in Drupal Core Drupal Core only lets you define and use components there are control modules there is one called CLDevel that will have a list of those and for each component it will tell you things like your metadata is actually correct and it will tell you you have all these files in there and these are your inputs and it will kind of introspect that SDC examples also contain apart from the component definition of the storybook stories and that can help you build the component library in storybook you have two ways enabling a Drupal module that will give you an admin interface that is bare bones but it has a list of components or you can go a little bit more advanced and write stories and list them in storybook we have a documentation page as you see up here that has a list of modules that are compatible with single directory components anything else in the back I can't hear all that can you repeat that a little bit louder please yes so the question is is it easy for a theme to override a component that is defined in a module and the answer is yes so what you would do is number one you would copy and paste that component only themes can override components modules cannot the scheme is of course need to match but you would copy and replace that component and then this you see at the bottom right here we have this replaces key you would put that in there then anywhere where that component is called the theme would override it that's a good question too so the question is let's say you implemented your own component solution which a lot of us have including myself and it's very close to this but it doesn't have the metadata file why switch over to using this and the answer is at some point the ecosystem the contrib ecosystem is going to be able to make use of this you know and if you do not have a schema defined at that point it's not going to work another thing that the single directory components module does automatically creates that library for you so you don't have to define that library separately but but yeah those are I think the main benefits anything else or two more I think over to the left first yeah can you add you said hashtags to the components I'm trying to think of a use case because this is just passing in some data that already it says so hashtags would be bubbling in before you're using the component so probably the answer is no but if there is a use case for it maybe we can chat tomorrow in the contribution day and talk about it and create an issue and work on that I cannot see a use case for that because most of the time the cacheability metadata waltz of the tongue would be bubbling before you get to the component inclusion in the page so the question is we talked about we talked about classy a little bit and your question is that we're moving stuff over from classy we're not actually moving stuff over from classy classy is actually removed from Drupal 10 and so within declaro theme and stuff we moved all of those style sheets into the reason that we did this as Mateo explained earlier is because we couldn't change anything with classy the markup was so stagnant the markup was written for internet explorer 8 or something like that and that made things really difficult so classy is removed if you're moving a component if you're converting a component into a single directory component like I did earlier it would be best practice to extract the CSS componentize it like if it's in a monolith take it out of the monolith and put it in here does that answer your question? so the question is if we're overriding a component from something else are we going to override the CSS and all that type of stuff the answer is yes so when you override you would literally copy and paste the whole directory and that includes the CSS and at that point you're the owner of the CSS and so everything on that is on you and then you would use that replace this key right there does that make sense? okay cool anything else? go ahead that's a really good question that's something we've been kind of spinning gears in our heads so let me repeat the question first of all is like a lot of developers will reinvent the wheels when they're creating their components and how can we share components and how can we do that? and that's a really good question so there's a lot of possibilities but we're still really really early right now so we haven't figured out how we want to do this but I mean right now you can distribute components in a module so let's say I could create a USWDS components module and that would have a whole bunch of components and at that point the themes could extend that but wouldn't it be cool in addition to themes and modules on Drupal.org maybe there was a component section or something like that or maybe if there was like the theme generator command line maybe there was a command line tool in Drupal or Drush that could automatically find something all those are possible but we kind of have to figure out where the community wants to go what is normal and what's really useful and also this is something that prior initiative tried to achieve called component and there was a challenge of people contributing components that it makes sense outside of my site to share that component some are generic, some are not when some are generic they tweaked forking that is kind of more work than starting from scratch so there are lots of things to figure out but it has been in our minds that's going to be the last one because we need to dismiss this class no sorry you get to ask the question and then that's it I say ask a question that's a good question the macro syntax you may have to repeat the question oh yeah I do have to repeat the question thank you so the question is let's say we're using a macro and we want to use that macro in several places and multiple components am I understanding that correctly so right now I would believe it would just be like the standard macro syntax to tell you the truth when I'm working with macros when I'm typing and pasting so I don't know that off the top of my head but I think there's like a use statement where you point to the macro I'm assuming that will work very much the same but that's something that we should try one of my goals that I have personally is like the Olivera menu system is really usable, really robust I would love to convert that into a single directory component and of course menu systems like that macros so at some point I'm going to be working on this and we're going to figure out if there is any pain in that right now single directory components is experimental which is really useful so if we do need to work on this it's a lot easier because with experimental modules we don't have to worry as much about backwards compatibility because it's in beta we still have to define a path but if we need to change stuff we're perfectly able to and if I get to be a little bit selfish and ask if you will be coming through the Compatibution Day tomorrow and explain me how to use macro so I can write a test for that, that would be awesome well I think that was the last one so just for the sake of the recording CatShaw is saying that within the CL components module which STC is based off of you have successfully used macros and they work as expected there you go alright so that's pretty much it right there because we don't have much more time but I appreciate all the questions and we're around thank you it was a really good session so you can say actually it was the best