 Thank you, Amy Joon. I appreciate it. And thanks everyone. I hope that number that Amy Joon just mentioned of 149 people is completely wrong. I can't imagine that many people are here, but I'm thinking it's only like two or three people, maybe. So thanks, both of you. But my name is Mario Hernandez. And today I'll be speaking about best practices for integrating components, which is a topic that in different ways. I've been talking about it for actually a few years. I've been doing training on this practices, writing blog posts, doing video tutorials. And so there's a lot out there to learn about this topic. And it's something that I find it very critical. And things that we should definitely consider when working with components on a Drupal 8 or Drupal 9 website, which is great because since we're still using Twig on Drupal 9. So all the practices that you'll see here directly apply to Drupal 9. And I think I, in fact, the demo that I have is on a Drupal 9 site. So you can actually see that working. So the idea for today's presentation is to talk about how you can rethink, mark up when you're building components, building the components. What to consider when it comes to building components related to Drupal, the things you should make sure that you account for when you're building your components. What those best practices are. And then we're going to demo how to integrate component with a Drupal 9 site and questions are welcome. And so please feel free to ask those questions and just a quick FYI, I've given this talk, I think it was like a month or so ago for the San Francisco Drupal user group. And that is an extended version of what I'm going to do today. I think that talk was maybe an hour and a half. And this is only half that time. So I'm going to skip some of the things here, but I have linked to that extended version on this talks page at the bad camp website. So if you want to watch that extended version, you are welcome to do. So I just don't have the enough time to do all of it here. So just FYI. I work for media current, which is a Drupal agency, well, digital agency that does all sorts of things when it comes to the digital world, development, training, front end, back end, digital strategy, SEO, accessibility and everything else. We are a 100% remote company and we are always looking for great talent. Our people are is impelled to constantly improve technology for clients and the community. We will like to always be able to get back to the community and be committed to that as well. So we bring great talented people to provide solutions for the web, our clients and the community. So if you are looking for a job, we have always several openings. So take a look at our careers page and hopefully you can find something you're looking for. I've been working with Drupal for over 10 years. I think it started 2007 and primarily as a front end developer and side builder. Now I am the head of learning at media current and I lead all the training initiatives, whether it's client training, community training and anything in between internal training. And I've hosted the media current open waters podcast right now is on pause, but we're hoping to resume that at some point. A couple of things I'd like to introduce is we just released a video tutorial series on YouTube completely free. It's called learning beat and every week I post new videos, short videos on various topics, whether it's front end, back end, accessibility, design, anything in between. And every week you can get those I think it's Monday morning. And so check it out, subscribe so you can get the latest notifications on that. And another initiative is that we also just introduced another YouTube series called Drupal theming with components, which covers a lot of the things that we're going to be talking about here. This one is a whole series that walks you from the beginning to the end on building a Drupal theme, using components with front end with call automated tasks pattern lab and all that. So those two things are great to learn more about this topic. And you can subscribe to both of those for notifications when new videos come out every week. So we think in the markup, right? I'm sure if you work with Drupal's, you know, before eight, right? Or even on eight, you may see something like this for for your project and this is not uncommon. Drupal is not known for producing the best markup or clean or semantic markup. So this is something that sometimes we have to deal with. This is actually something a project that I worked on, where the only thing if you can imagine the only thing that was printed here was a link for an Instagram social media. And so you can imagine how horrible this is not only it doesn't provide you any meaning in a semantic but also performance plus it's just not necessary all of this, right? So the beauty of components is that you can write your markup and you can make things a lot cleaner. Here's an example of for example a card, which is the example that I'll be going with today. And you can see that things just look a lot nicer, right? Things have more semantic meaning when it comes to the CSS classes that you use, the HTML tags that we're using a lot better than just a bunch of divs. So the idea is to think about how you can optimize the markup that you write so that it works better and also performs better. Not only for, you know, as HTML and CSS, right? But there's a lot of things that go into here responsive design. You know, when you write your markup, think about how this markup is going to behave when you are switching layouts, right, between mobile and desktop. How is that going to affect is the markup going to work for you? Is the user experience going to be such that, you know, it's going to be natural transition between mobile and desktop, right? So there's a lot that goes into performance, right? You know, if we think about that previous example, it was once feel and there were probably more divs than there are here, which is an entire component here. And so performance is key when you're writing your markup. Accessibility is critical, right? We want to write markup that naturally lends itself to assistive technologies, right, that people with disabilities are able to understand and navigate the content that you are providing on your website. And so SEO, right? If you are writing great markup, in turn, that is good for SEO. Search engines, a lot of that kind of stuff, you know, properly structure headings, properly structure HTML5 tags, that kind of thing. Usability, obviously, good markup will produce good usability, right? You'll be able to interact with that application or with that component much, much better when the markup is such that it allows you to work well. As an example, if you have a form and you are using the right type attribute for that form element, right? If you have a phone number, if you use the type of tel, or if you have an email field that uses the type email, then when you are interacting with this form on a mobile device, you will get the respective keyboard for that type of form element, right? So it's not just to drop in any field on the form and expect that things work just right. So there's a lot goes into it. And one as a developer called maintenance, right? How much easier would it be to manage this component here than the previous example, right? And so there's a lot more. So again, reusability is key, and you'll see that in my example in just a moment. So let's, we're going to build the component. And here are some of the best practices that we'll use. Again, I'm going a little quick because I'm supposed to be skipping some of these things. And so, so semantic markup using BEM block element modifier is a great way, which is what you just saw there in the previous example is naming your CSS classes in a way that makes sense in a way that tells you that things are associated with each other. There's some kind of relationship when it comes to Drupal, when you're building components, even though you may be doing that in pattern app or some other design system, you need to make sure that you are accounting for things like Drupal attributes, title prefix, title suffix, and you will see how that affects how your component is rendering Drupal. Includes and embeds, tweak blocks, view mods. And so those are all great things to keep in mind when you're building your components. A lot of people think, okay, I'm doing this in pattern lab or some other design system. I'm just going to focus on this one thing. They don't even consider what's going to happen when, when it comes to Drupal. So, but, but it's important to think about that even before you get to Drupal. So here's the example that we're going to be kind of playing with today. The one on the left, primarily, again, I don't have the time to show the one on the right. But it's just a card and people say, well, that's just a simple card. What's the big deal? But this is a card, the same card that we were describing earlier with the code that we were looking at. And so think about how you can use this multiple cards, right, in different ways. So here you can see that the same card can be used in many other ways. And so that's why I mean when I said, you know, writing your great markup to ensure that you can account for all these different variations of this one single component is critical. And so I'm going to now jump into code and I'm going to see if I can show you a quick demo on how this works. So I'm going to try to extend, increase the font size. So it is easier for everybody to see. So what I'm going to do first, I'm going to quickly launch pattern lab, which is where I have the component. And we're going to show you that card that we were just looking at, right? That's the card that we eventually are going to be integrating with Drupal. And let me see here. Here's the card, right? So nothing special about it. There's an image, right? There is a title, there is a date field, there's a teaser and some tags, right? So if you think about in Drupal terms, each of these will be a field on a Drupal content type, for example, right? Like a news or a blog, right? So we have an image field, a title, a date, teaser and some taxonomy terms. This doesn't show things really well so instead I'm going to inspect it so we can kind of see how this card was built. I'm going to collapse this. So here is the card. It's got an article tag with the class of card and then it's split in two parts. One is the media and then the rest is the rest of the content, right? So this in itself creates a lot of flexibility for you because now you can move things around. And rather than moving individual fields around, you can just grab the whole container and move things around. As a quick example, I can say instead of row, column display for flex, I can do row and you can see that now the card is horizontal and will show more of that. In fact, if I scroll down, I have a horizontal version of the same card. This is the exact same card just with slightly different styles. But none of the markup has changed. Absolutely nothing. The only thing that this card has that the other one doesn't is that this one has a new class here. In addition to card, it's got a card horizontal class and that's the only class that I'm using to flip it horizontally. All the markup is the same. So this is exactly what I meant is think about how your elements on your page will be affected when things switch from mobile to desktop. And the markup should be able to adapt to those changes. So that's the card. I'm going to show you this now in code and we can kind of go over some of those practices that I talked about. So in pattern out, typically you will have either a JSON or YAML file for your components demo content. You have your SAS file, and you will have a tweak template for your markup. Sometimes you will have JavaScript as well. But typically these three files is what you'll need. So the first thing is we have a JSON file, which is where we've defined each of the fields for the card. Here's the image field. And I have the full image tag here. The reason for that is because when I get to Drupal, rather than stripping pieces of the image like the alt tag or the source, I want the full entity to be provided to me. So that's why I'm already thinking in that sense here. For the title of the card, I have a heading component that allows me to change the heading level like H2, H3, H4. It allows me to add a modifier class, the title of the card, and also a URL if the link, if the title needs to be a link or not. So this has been built in such a way that I can alter any of these things when I use the card or the heading. Then we have a date field, a body field, and then an array of items for the taxonomy terms or tags. So I'm already thinking of what is Drupal doing for taxonomies? How is Drupal going to render those taxonomies on my page so that when I build this component, I can account for maybe those variable names already, so that I don't have to figure out other ways to change the way Drupal is doing things. Sometimes it's easier to let Drupal do things the way it does and you adapt your component to how you want to do it. In other cases, it's better to do the other way around. It's just a matter of knowing when. And so for example, this name and URL are very key names. These are the names that Drupal uses for taxonomy terms for the label and the URL of them. So I'm already using those. As far as the markup, you can see that I started with an article tag and a class of card, right? And then I am checking whether there is a modifier, right? So if you look at the JSON file, I have a modifier key here that by default is empty. A modifier is basically a way for you to be able to pass a CSS class to a component. And you saw that earlier when I show you that card underscore underscore horizontal, right? So that's how I'm passing that class there. So I check whether there's a class being passed. And if there is, I add it as a class right here. The next thing I do is I check, is there attributes? Obviously in pattern lab, we are not dealing with attributes, but I'm already thinking on Drupal, right? Because that's the goal. I'm going to integrate this with Drupal. And so I'm checking, are there attributes? And if there are, then print them. In this area here, just print the classes of those attributes so that they can go along with these classes here, right? And then I check again, are there attributes? And if there are, print them, but without the class. So give me everything else that is not a class. Things like ID or data attributes, right? Put those outside of the class attribute. And so that's what, this is what this is doing. So I'm already thinking on Drupal there is how I can account for what Drupal is going to need when this component is rendered, right? And you'll see in a minute why that is important. And then I'm going just to basic conditionals to check in whether the content is there. And if it is, then I print the respective markup for it with the variable for image. So this will print a full image. And I check first, because I don't want to print empty wrappers, empty dibs, right? So I check if there is a heading or title. Then I put the title prefix here and then title suffix. This again is Drupal things that I don't need to really care about and pattern up, but I do in Drupal. And so here I'm just including or nesting a heading component that we have already built that is here. And it's just the same structure as what we just saw there. This is what the heading component looks like. It checks whether there is a link on the heading. And if it is, it prints the title wrapped in an anchor. If not, just prints the title as plain text, right? That's what the heading is doing for us. And I could just go through the list. Again, if there's date, I include this component called eyebrow and I print the date variable and I pass this class. And then the body, the same thing for the taxonomy terms. I pass a tags component that we have built already. And here it is. First, I built a single item, a single tag, and you may wonder why it was that way. Well, that's how a Drupal actually does it. When you'll see in a minute that Drupal first, it has a template for a single tag on a taxonomy vocabulary, and then it's got another template for building the collection of tags. So I mimic that in the component level. I build a single tag first, and this URL and name variable is what Drupal is using. So that will make it natural for Drupal to be able to, you know, integrate itself into this component. And I'm also using attributes here because I noticed that Drupal looks for those attributes on the tag, on the individual tag, and you'll see how those work. And then I have the collection of tags where I check attributes and I do a for loop. And then I say for each item on the list of tags, print a list item and include the single item tag that I created up here. So I'm looping through that and including a single tag item. And in pattern half, the way that looks is if I go to components and go to tags, you can see I have the list of tags. Right. Those are the tags. And if you're wondering, how come this single item is not printing on the page? I'm using the underscore at the beginning of the name. And what that does in pattern half is pattern half ignores that from displaying it on the page. However, it's still available to be used because I don't need to see a single tag item here. I want to see a collection of tags. So that's why I'm hiding the single item from pattern half. But I'm still able to use it right here. I'm using it here. So that's how the component was built. So now let's take a look at how this will be integrated in Drupal. Right. So let me go to the Drupal page. And Mario, can I have a question, please? Sure. Caroline asks, do you reuse things like tags or title templates in different components? It depends. Sometimes you can. Sometimes you can extend templates. And so if you build that system where you have updated your template in a way that the code could apply to multiple components, then you can use extends. And then you will just update the things that you want to change for that specific component while still taking advantage of a more global template. Yes. That is definitely a good practice to have for the question. Okay. So I'm going to just open here in the same window. Okay. So here is the Drupal page. It's basically all I did is I created a content type called blog. I added a bunch of blog posts, you know, with the image, date, right, body, some tags, the title, and it's just a bunch of them. And what I'm going to do, if I inspect this, I have debugging, tweak debugging turned on so you can see all the fields, the template suggestions and everything else. Like here is where this article starts right here. It's an article. And you notice all these attributes here, data, quick edit, the role attribute, the class, all those things. Those are attributes provided by Drupal, right. And so when we build the component, we want to say, okay, I want to be able to allow Drupal to still inject this attributes on my markup, even though I'm customizing my markup. The other thing is, if you notice when you hover over the content, you can edit, right, you can edit the content. And I would like to be able to keep that as well, right. Even though I'm using my own components, I want to be able to still edit in line the content. Just to me, that's a nice future for some people, right. For editors that could be very easy and quicker to edit content. It's not required. So if you don't need that, you don't have to include it in your component, but I wanted to. So and we did that in our component. We did the attributes, right. So all those attributes will be injected on our markup. And here we have the title prefix and title prefix and suffix, which is what will allow us to edit the content in line. If we don't have those things, then those that functionality will be lost in Drupal when we use our component. So going back to here, I'm looking at. So what I'm using here, this is a blog post. So this is a full node, right. So when I click on it, it takes me to a full node, right. But I'm looking at it here in teaser mode, right. All these are teaser views of the other blog posts. And so what I'm going to do is I'm going to say, OK, which template do I need in order to modify this so that I can create custom templates for it. So we simply we basically we need a no template. This is a blog content type. So we have all the suggestions of templates names we can use, right. And so I see that there's a node blog. That's great because the blog post, but I want to go a little bit more specific. I don't want to update all the blog templates for all the nodes, right. I want to be very specific to only updating this list of content. So what I want to do is instead of saying just node blog, I want to do no blog and I want to use the teaser view mode, which is a specific view mode for this list here. So that's what I'm going to do. And I'm going to go to my templates directory on my theme. And I have a node. I'm going to comment this for now. That's the kind to show me what variables are available on my node. So here's what the default template looks like from my base theme, like whether it's stable or mean, classy, right, one of those two themes. This is what a typical node template looks like. So this is what I need to update in order to integrate the component that I built with Drupal. Right. So again, in the interest of time, I'm going to see a little bit here just to be able to think this is the one going to my theme custom. This training thing is my theme name source template. And this is for content. So I tested a template. So basically I have the original template, right, the node template. And in order to override it, I don't want to override for all the node, the blog post. I want to create my own template suggestion and I wanted to go node blog and the teaser view mode suggestion that we just saw. So this is what we're going to use. Typically when I update my own templates, I still like to keep these comments because these are very helpful. They give me a lot of information of variables that are available to me on the template. So I always like to keep those. And then I start and I start overwriting things, right. So I'm going to go down the list here, although I have all the code already in place here. I'm going to go down the list. The first thing I do is again thinking that I don't want to break any functionality in Drupal. I want to make sure that my full content array is available on my template. And because if we're going to be stripping fields out of the content array, that could lead into issues with caching, right, if you're not accounting for the full content array. So I just declare a variable just to trigger the full rendering of the content array. This is not going to be used. It's simply just to kind of wake up Drupal say, you know, there's a full content array here, be aware of it. I'll come back to the date shortly. And then what I do is if you notice the title of my card was structured in such a way that I had a heading level that a class, the text of the title and then the URL. Right. So what I'm doing here is I'm setting a variable. I don't have to do this, but I'll explain to you why I do this. I set a variable for the title. And then I pass each of those values, right? What heading level do I want? What class do I need to pass? The text of the title, where is that? Okay. If I look at the variables up here, you will see that label is what one of the variables right here. Label is the title of the node. So that's what I'm using as the value for the title text. And then the URL, same thing. The URL is up there. So I'm passing that as the value of the URL field on my heading component. Then I'm using a embed. And if you are familiar with includes and embeds and extends, if you're wondering why not use an include? Well, an include simply lets you bring in your fields, but it won't let you do anything with twig blocks. And in our component, I created a twig blocks. I'll get into this in just a minute. But that's the reason I'm using an embed is I want to be able to manipulate a twig block that I created in the component. And then I link to the car component that we created in pattern. Now, this here is a namespace unique to my theme that I can use to automatically link to my components. And this requires the use of the component libraries module. So you need to make sure that you have the component libraries module enable. And in your info file, you will see that the component library modules allows you to create a namespace, which is this here, which you can link to any directory on your theme. If you notice that Drupal by default will only look for twig templates in the templates directory, right? So with this namespace, we can actually look for twig templates in any of these directories. And this name is arbitrary. You can assign any name you want to your namespace. Typically what I do is I assign the same name as my theme name just to make things easier. And, you know, I can go to any project and I know what the namespace will be. But this could be anything. And so, but this requires the use of the component libraries module. So, so that's what this namespace and then I'm passing each of the values. Okay. So here's the car component. And these things on the left of the column here are things that are coming from my component. All this green things, right? All these variables. So I have the attributes that I added to my component and I'm matching that to the attributes of variable available on this template. Right. If I go and look for attributes, there is, there's a variable there for attributes which Drupal uses to inject HTML attributes to my markup. And I do the same for title prefix, title suffix, right? These are coming from Drupal here. And then for the heading, the title of the card, now I'm using this new variable that I created up here. So I'm saying map this heading variable to this variable here. And because the structures are the same, they all, they both have all these keys, values, then they will automatically match. And then for the image, as I said before, I'm passing the full entity of the image. And this is just checking to make sure that it is not empty at all. That is full. There's content before I print it. But this gives me the entire image entity to print. That way I have everything I need about the image and then caching is not broken down. Then I have the date field. Date is another variable available on this template. And then the body text. All right. I'm just passing the field name and checking to make sure that it's not empty. Now, for the tags, this is different. So if we go back to our component, how much time do we have, Amy June, for like 10 minutes? Yeah, you have about 10 minutes or 15. We're not really in a hurry. Okay. Thank you. Okay. So on the tag on the card component, see how I created this tweak block to block is a great way to override content to inherit content and to replace content on your templates. I have a video on that on learning beats. If you want to check out what we blocks are, how they work, how you can use them. So what I'm doing here, the reason I'm doing a tweet blog is because the format that I have for my tags is not exactly how Drupal is going to give me that on the Drupal side. So I'm creating this here for pattern left, right? So I can display the tags, how Drupal is going to do it. But I'm doing it in a tweet block so that when I get to my template here, I can then let Drupal just print the tags, however, Drupal wants. And as I said before, Drupal uses two templates for taxonomy terms. One is for the individual item, which is this one here. And one is for the collection of items. So let me bring in those two templates. Let's see here. Let me close all of this so I know what's happening here. Okay, so I have that. And sorry about that. Let me just, I will ensure which window was which. So training theme, source templates. Okay, so this isn't my theme. So inside content, I need to copy the template for the individual item, the individual taxonomy term. So again, I created a quick template suggestion. This is the original. And I created a copy of that and named it taxonomy term slash tags. And this is, you know, it's found in Drupal. If I inspect the tag here, you can see that that is right now Drupal is using the default one taxonomy term, but I'm going to create this copy here taxonomy term, dash, dash, tags. And that's for the individual item. And so now that I copy that, I'm going to, I'll come back to refresh my cache later on. So let me show you what this is. Again, I'm leaving all the variables available on my template. And what I'm doing here, because I know this is the only the single tag item, right? All I'm doing here is I'm including the single tag item that we build in our components. Remember that one started with the underscore. And because Drupal uses, where is it content, right, but content uses the URL and name here we go. This is the URL variable and this is the name variable that Drupal expects for each tag. So because our single item tag was built with those variables, the name and URL. When I integrate it here, Drupal will know exactly where to plug in its variables into this component. So I'm just integrating that. The next one is the collection of tags. Again, I'm going to go here. This one's under the field. And I'm going to go back here. So this is what gives me the full collection of tags, right? And if I go here, again, I leave all my variables there. And this time I'm embedding the collection of tags, the tags component that I build it by now. And in there I'm also using a tweak block because I don't want to be manipulating how Drupal wants to structure the markup, how it wants to structure all the different pieces. All I'm saying here is I'm saying, give me the tags component and in here insert whatever Drupal wants to do for the tag, which in turn means it will insert this item, this single item. So if we look at the tags here, you can see that I created that tweak block for tag item and in there I'm nesting the single item, right? This is at the component level. But in Drupal I said I have a single item already integrated. And then on here, bring me the full collection and let that single item be inserted here. That's what that means. So that's what tweak block allow you to do is allow you to override, change or alter the text or markup that you want to do. So now that doesn't place, now that we have our blog teaser mapped. And so now for the tags, the one thing that we left here is I have that block again for tags, right? From the card. And I'm saying, pass me whatever the content is inside this field in Drupal and the content type, content, field, blog tags. This is the field that when we create a new blog post we select the different tags on. So I'm just saying just pass me whatever is in there. And because this field has been basically integrated already in Drupal separately through the tags, then Drupal would simply insert the content of those templates in here with the data of it. So let me clear my cache now. So here are our cards now. They look exactly like they do in pattern lab. And now look how I can edit them right here in line. And if I inspect this, you can see that here is the image. Okay, so here's one card. So it's got my class there, but look how it's got all these attributes that we saw before. They're still there because we made placeholders for those in our component. So all of that is still there, right? And in addition, I got my quick edit links that still allow me to edit all of that content right in line. And so now we have these cards fully integrated with Drupal. If we look at, again, the markup, you can see that things look so much cleaner now, right? Because we have, there's one other template that I wanted to copy there, but that's okay. That's just for styling purposes. But the main thing is that we have not only do we have clean markup, but we also still have access to all of the Drupal important things that we need like attributes, title prefix, title suffix, which in turn allows us to ensure that caching works properly, that we have a single source of truth for the component. And that is patterned out, right? If I want to change anything about this component, I will go pattern out, make the change there, and Drupal automatically reflect that change because it's completely feeding off the card and patterned out. So I know I rushed through this. Again, there's a slower version of this that I linked to the page. So if you want to check that out, please do. But this is how I typically work on components. These are some of the best practices that I follow to ensure that not only am I adhering to, you know, general development practices as far as markup styles and everything else, but I'm also ensuring that I'm not breaking things in Drupal and getting rid of things in Drupal that would be critical for things that Drupal may want to do performance caching and things like that. So as far as styles, very straightforward, you know, the nice thing about BEM is that your styles become very flat, very easy to maintain and manage. There's nothing over engineer here is as straightforward as you can imagine. And so that's another advantage. So you can come to this project six months later, and you can still figure out what's happening here. You know, there's you're not going to see all kinds of non related styles here. Every component has a styles only specifically to that component. So that eliminates the regressions or the chances for regressions. And it just makes your code much cleaner, easier to maintain and not over complicated. So that's all I have. Are there any questions I can answer? There weren't any additional ones in the chat. Okay. Let's see here if I can cover the heading component is one that I when I do my training if you've done some my training is probably one of the first component that I asked people to build, because it may seem a simple thing right just printing a title on something whether it's a component page or anything else. But you can still build it in such a way that it is flexible that is powerful really what we're doing here is we are passing a variable for the heading level, meaning that this will allow us to change the heading from h1 h2 h3 h4. And if no value is passed by before we make it an h2 we are checking whether there are mortifiers so we can pass additional CSS classes to our component. If there is a URL that means we most likely wanted the title to be a link. So we wrap the title text in a link. Otherwise, we just print the title as plain text. So that's a simple but then when we're using this component right like if we go to the card. That one. When we go to the card and we want to use that heading component. Then we will structure the same way. And here's what we can pass things like you know what what heading do I want what color as well what is the title, is there a link or not if it's not a link. I'll just leave that empty. And then the title of the card would seem to be plain text no link. So, so that's Markey has a question. Yeah, you would like to know why pass the rendered image in your pattern instead of image data. Yes, good question. So, ideally, you want to kind of be able to have access to the full content array of data right in your in your node pages and stripping like I said before stripping things out of that. Okay, it's just not recommended it's not a good practice so I rather have the full entity available to me, because if I inspect this for example. If I look at the image, we have all of these things here now, all these attributes. If I go even higher, you can see that all these was included as part of including the full entity for the image, all of this. So, we may look at this and you know I don't even know what that means I may not need that probably right, but group may need that right to do caching to do other things. If I was to strip the image and just use the old attribute and the source attribute that will be the only things I will see here. And all of the rest of the stuff will be gone. And to me that's just not good practice. I don't want to break the way things Drupal wants to do some of these things. However, I still want to be able to have control how my markup shows up or how those attributes show up right so to me it's better to just let the full entity be available and and and it's just yeah.