 Hello, everyone. Thank you very much for coming. Appreciate it for room. Well, that's awesome. It's great. Great seeing everyone. People sometimes only see a conference and stuff. It's awesome. So thanks for coming and thanks for coming for the presentation. So we are going to be presenting on practical componentization, improving Drupal development and site building. So basically what we are using is StatenLab and some other tools to automate and to make a front end a bit better than what Drupal outputs. As you guys know, Drupal is not very good at outputting the front end, as we are good at creating the back end. And even Doris actually agreed that Drupal made always sure to work on the back end and have a solid back end. And now Drupal H, we are working more on the front end. So this is stuff that we kind of are finding to help make things better. So this is what this presentation will be about it. So we are going to be doing a talk. I'm going to go through quick step-by-step of all this stuff that we are doing. Then Homer is going to do a live demo, fingers crossed, because nothing can go wrong with that live demo. And then we will have questions in QA. So if you guys have questions and stuff, write down and then at the end we will be answering other questions and all that stuff. It's quite a bit to absorb and everything. But hopefully the goal of this is at the very end you guys will be able to go home and then install this stuff and they got to work on the Drupal H site. So my name is Pierre Marcel. I am a Drupal front end architect. That's what I like to call myself. I've been working with Drupal for a long time. I started with 4.6 back in 2006. And here I am still and I love it. You can find me at Drupal.org. I love helping people. I am one of the organizers for Drupal TO. So if you guys have any questions about that, please ask me. And recently I am a freelance developer. And recently I joined therefore in January. And Alex was crazy enough to let me do this stuff. And then he was crazy enough to give me this guy. Which is freaking awesome JavaScript to do it. And then we brought what I was doing to the next level. So I'm very happy to have joined therefore and do this stuff. So my name is Sean Homer. I go by Homer because we have two Sean's. So it's easier to remember. That's much cooler too. And it's much better. You get used to it. I've been a developer for over 10 years. I'm a senior developer at therefore. And some of background in Node.js and JavaScript as well. So Drupal is still newer for me. But at therefore we've been given a chance to start looking at technologies like this and ways to improve things so that we're not, you know, doing the same things over reinventing the wheel and finding ways to improve things. And we have the latitude of therefore. It's been a very good situation. Okay. So let's start with some basics in here. So what is a component? So I assume that pretty much everyone knows what a component is. So it's been around for a little while already. So basically a component is extracting a piece of the data or content from a website and identifying that and the basic encapsulating this. That's what a component is. So you better try to find the definition for it. I went to Wikipedia and then I did a search. And that's what it says. So and of course, it depends for the industry that you are. One thing that I liked was this part here. Incapsulate a set of related functions or data. And you know what? For us web developers, that is exactly the meaning of a component. So when you're thinking about a component, that's what it is. A component can be a large piece of related functions or a very small one. And we will see how that works. So basically we have here a few different components. Okay. So here is a very simple cultural action three app component. As you can see in here. So we have a title. We have subtitles and then we have a little blurb and then a button. And here is another component. As you can see, we have some SVG measures. We have this here. This can be also extracted on this way. So this would be one component. This one is a group of components. Okay. And you will understand why pretty soon as you start explaining. Here is another one. A social media component. And here is a very easy simple footer menu. For example, that's a component. If we have a mega menu, that would be a component as well. So that's what a component is. So now the question is why componentize? You may ask. And the answer is right here. So how many here are you guys from end developers? Okay. So you guys know that if we remove the CSS from this, it's all the same thing. And here's the thing. Back end developers, you guys write once and reuse. That's why we have modules in Drupal.org. From end developers, we reinvent the wheel every time we try to do something. And I'll explain why. Over here, we have title, blur, bottom, background image. Title, blur, bottom, background image. Title, blur, bottom, background. Background image, title, bottom. So why we keep reinventing this HTML markup every single time? Because that's what we from end people do. And we try to reinvent the wheel every single time. So the reason why it's componentized is because I'm tired of freaking writing this. I want to have it ready for me, finish, and go drink beer. Because that's what we do, right? When I start working with it, I start working on a few different ways of how to achieve that. And I came across this thing called atomic design. So have you guys heard about atomic design? Yeah? So it's an awesome guy. So what is atomic design? Atomic design is a methodology on how to organize components in a clean and methodical way. And it can be for anything. So it's not only websites. So for example, I use atomic design for building my IKEA furniture. So I have a 10-year-old daughter. And her job is when we buy IKEA furniture, we open the package, and then we separate every single little screw, and then we put them on the floor, just like this. And then we start building. By the end, we know how many pieces we have of each, and it's much easier to build that IKEA furniture because now I know what's being used, the size of the screws, side by side, and everything. So it works for anything. Works for a tangible life thing, like we are doing. And it works also for a website. So that's given as an example in there. So everything's messed up. That furniture can build something in there. You know, we all will be able to build something if we were giving this. But if we organize in a way, now our brains start identifying, and we are able to start having ideas to build different things with the same thing that we have. And also, at the end, we will know how many things we had and what we could build. So that's what Atomic Design is. It's nothing more than a starter point of a methodology that you can start and adapt. So do I follow Atomic Design exactly like Brad Foster wrote? Probably not. I write his book twice, and I follow the guy, and I love what he's done, but I did change a little bit for the things that I do. So here's the dude who created. There is my guy, and he was tired as well of this chaos in design. So he came up with it. I like to give him, you know, point, and that's what that is. So how does Atomic Design work? So basically, Brad's idea was he had to find a way to organize. If you're going to organize something, you have to name. How you name? You know, for you guys and developers, you guys know that naming a component or something is as hard as naming your kid. Because as soon as you start naming, you're like, oh my God, does it make sense? You know, the next person is going to come down. Is that going to make sense? Am I going to look stupid for calling this this? So I was creating a button a couple of days ago, and it's the mobile toggle, and then I called... Menu hamburger. Menu burger. Because it was pretty funny. And then I pushed to our repo just so Homer could see. And Homer's like, dude, I think menu burgers are a bit weird. I think toggle is better. Dude, I love burger. But anyway, still, that's a little joke. So, what he did is he went back to his high school times, and then he went to chemistry and I'm wishing. So, you guys know the atom is a very small little thing. It's an atom. A molecule is a group of atoms, but limited to a group of atoms. So about maybe one, two, three atoms. Then organisms. Organism is a group of atoms and molecules. Or molecules. And then he ran out of analogy on his chemistry. He decides to name templates and pages. Right? It happens. So, and here's what it comes. Do I follow him exactly what he's doing? No, because in Drupal, templates and pages is kind of... We have already that name space. We use templates for something else. So, we decide to change and we rename muccaps and the layout. So, we switch this to layout and this to muccaps. And as I go, you'll see why. So, that's how it works. Atoms, molecules, organism. So, you hear how it works. It's pretty cool. So, you have an atom. And atom will be like each of those. Now becomes a molecule. Now becomes an organism. Now becomes a template. And now becomes page. So, that's how atomic design works. So, now here's the thing. Let's go back a few screens back and then think about the little tractor that they were building, the little car and all that stuff. Imagine buttons. Now we have a list of buttons throughout the whole site that we know it's in there. We have a list of titles. For you and developers and for you guys both sites, you guys know a lot of designers kind of say, that font is not 22. It's like it is. I put it in the back. No, no, no, it's not 22. If we have this living style guide, it's like, yes, it's right here and you can see. So, that's what it is. It's really good for displaying and kind of building this thing. So, that's how atomic design works. So, now let me get my water here. So, a lot of people, they confuse Panelab with atomic design. And it's two different things. So, atomic design is a methodology to organize components. Panelab, it's nothing more than a living style guide. And the reason why people confuse is because Brad Frost created Panelab, sorry, atomic design. And then he knew this guy called Dave Olson, which is a programmer. And he said, hey, I love the stuff you're doing with atomic design. You need something to house all this stuff. How about we write a living style guide for it? And he said, let's do it. So, when they built, they built using atomic design. But Panelab is nothing more than a living style guide. And what is a living style guide? A living style guide is a set of tools for managing, passing back names in UI and organizing in the visual way. And outputs, static HTML pages that goes into a folder, which you can push into your server. And now your designers, your clients, your co-colleagues, your boss, everyone can see the work you're doing. I'll organize the way which we'll show. So, Panelab runs on htnode, but you don't need that to see the page, because, like I said, once htnode does what it has to do, it creates a static HTML file and put it there. So, Panelab have a few additions, that's what they call it. So, it's all running in htnode. And we have Musash, we have Twig, we have Drupal. Drupal is broken in Panelab, because they're not maintaining. So, there is a little fork that is happening now. So, just be aware if you get the one from here. I think I have a link later on. And then they have Thin. Thin has nothing. It's Panelab and Thin, and you come up with whatever you want to use as a template. It's up to you. So, use your own methodology. So, Dave Olson wrote this for breadfrost, and now they have a new maintainer as well, Brian. So, this is what Panelab is. So, it's nothing more than a living style guide. So, here's an example of the page. So, here is actually the page, the mock up what we are calling out. So, this is all loaded from Panelab with data modeling coming from a YAML file. Okay. So, Panelab and Atomic Design. Every time when we are giving a component or a task to build something, we look at this as a front-end developer, and we say that's pretty simple. It's a testimonial here. Okay. We can wrap this into a div, another div, another div, another div. So, four divs, one wrapping the whole thing. Boom. We have our markup, right? Yes. But now if we start thinking about Drupal, what does Drupal do? This is what a Drupal is. I actually built this. So, kind of embarrassing, but back in the days. So, anyways, look at this. This is what we call a divi, that's right. So, it's just a goal, this craziness thing going down. No. Let's throw your testimonial somewhere in here. And all this stuff around and everything. And it's just crazy. It's just crazy. It's just insane. And that's why Drupal got a bad rap, because of this stuff in here that we used to do. So, that's what we are trying to solve. So now let's go back. Let's go back to our component. Forget Drupal for a while. Let's go back to our panel lab and our atomic project. Okay. So, to run a component into a panel lab, how do you need two files? The docked wave file and the YAML file. That's it. Once you create that, you can write your mic up. And then your demo data goes in here in your YAML file. And that's it. So now, let's say a client is not just sure or the testimonial is not fully approved. They say that this part in here won't be the name of the person that will be the city. So, if we would do that in Drupal, we would create a field. We would name the field after what it is. Now they told us to change it to a city. Well, now I need to do the location. What I'm going to do? I'm going to have to go delete that field in Drupal, create a new one, and add that data. And then you'll know how long that takes, right? In here, this is the sample of our docked wave file. So, going back, when we are assigning tasks, we wanted to do this as simple as we can. And you can write in many ways. Actually, it's two years in Spain. It's supposed to be different here. So, you can write super clean. And that's how it works. So, using Petarab, what you do is you create variables that make more sense. Okay? And then you'll see how we're going to file this whole thing. So, you create a div, div, div, put your variables and everything in there. And everything is pretty. So, then you create your YAML file. And as you can see, it goes. So, it just works just like an array in Drupal. So, we have testimonial, author, name. Testimonial, author, name. And this is how we organized. You can do name, author, position, company, one below another. So, nothing stopping you from doing that. So, now I'll ask you what is faster and easier when the client changed their mind because you're building on the fly. To change a static YAML file or to change the Drupal field in the database. Definitely this one, right? So, that where the power is and that's where we are gaining speed. Okay? So, prototyping. Super easy. You just create this. Reusability. Because we are working on components. Now, I'll say, hey, you know that, that testimonial thing you made there? Can we put in this other site? Sure. Drop. Done. So, once you create that, this is what a better not leaving side of that thing will look like. It's pretty cool. And this is created on the fly for you. It shows you the quick fly. It shows you the HTML markup rendered with the data. And then showing your component is styled. So, it's super cool. So, now we want the designer to sign off for the president to sign off for something and send this and they say, looks good. Merge that to Dowermaster database. And so, we do. Okay. So, you got to say, okay, cool. You're home. How the heck we tied this into Drupal? Well, that's a good question. There are a few things we need to do before we get there. There's one piece of a thing that we need that's required, which is a module called Components Library. It was created, it was built by John Alban. You guys all know him. And he wrote this module. It's a very simple module. All it does, it allows Drupal to load a non.html.tweg file into Drupal. Because, you know, if you don't have a .html.tweg, you won't load. And, as you notice, all my Tweg files were actually Tweg files. I don't know why in Drupal we do that. It's like everything we got, we want to change. It's like, why don't you use .tweg file? For some reason, I never wanted to look for this. So, he wrote this module that now allows us to render a .tweg file and also outside of the template folder. So, that's pretty cool. So, things that will make your life easier. Even if you're not doing anything, then I don't have anything. This year, it's a pretty awesome thing. So, Tweg, Tweg, Tweg, Field Value, and Program. So, this module here grabs the data. You know, in Drupal, because in Drupal, you have your field. The field is wrapped into a field template. The field template is wrapped into a region. And then it goes into your page. So, when you load that variable, that field into your template, it's loading everything. And now, if we go back a few slides before, I don't want that DBI that's in my thing. I want to have my data. I gave my data to you, Drupal. Give it back. And I don't want your DBI that's in. So, this year, we'll put the content, the data from that field. It's pretty cool. Tweg, Tweg, it's really awesome. I'm not going to go through. But you guys, this presentation will be available on the page. You guys click download, use in your Drupal 8. It's awesome. And paragraph. How many people here have you used in no paragraph? Pretty much everyone? Okay, awesome. So, paragraph one. So, in a building component way, we could create our components. We could create our field and put it straight into the content type. But we wanted to reuse and also, nowadays, every single website we built, it's kind of this stackable sort of a website, right? So, because of that, we decided to use paragraph. So, paragraph, I don't know if I should spend much time explaining exactly what it is, but paragraph is a Drupal entity, right? So, we have blocks, blocks is an entity. Content type is an entity. So, paragraph is an entity that you enter. You create fields, enter data, but you have to use another entity in order to display. It's not self. You can't display self or anything. But as you can see, we can create our fields. We can name and we can do everything when we want. There's the managed form of display. There is the managed display. It goes out like that. So, just like content type that we have. So, once you create your paragraph, you have to inject inside the content type. Or you can inject inside the block type, because it's an entity and it's fieldable. Or you can inject inside your taxonomy term, because that also is fieldable entity. So, we use this field called entity reference revision. Okay? So, we create that. And remember, we used to build on our content type. We have title, we have body, we have button, link, blah, blah, blah, blah. Now, we have this one here. And you can add multiple reference fields and stuff. So, but we're not going to get there. So, once you added that field, it gives you this option to choose which paragraph type you want it to add into that list. Because sometimes you're building a landing page, or you're building a news page, and you don't want to give the whole kitchen sink to the editors. You want to just give it what is more specific for that particular content type of our page. So, you can check, check, check, and that's how it's going to be loading in there. So, it's pretty cool. Okay. So, now, to find this into Drupal, right? So, now, we have our component. We have, it's all styled. It's all in there, in the internal lab. Now, we created our entity, our paragraph. We checked our paragraph inside our content type, because that's how we want it to display. Now, we need to connect this to. So, and now, that's how it works. So, everywhere we have created entity that we created in Drupal, you guys know that we got a namespace for a file. So, with this file, what we are doing here is include, okay? So, you can do this include with anything in Drupal 8 in the end of going from one template to the other. Now, we are pointing to the .tweb file that we created early on for our testimonial inside the monarchy, and that's how it works. So, now, this part is in here, it's not complicated, but remember the YAML file that I displayed? Exactly the same structure. Check it out, testimonial, style. This is simple because it's the way that we style our things. So, it goes as a data dash. Then, we have quote, which now we are mapping field to variable, field to variable to field, variable to field. So, this is Drupal, this is Fetal Lab. Okay? So, that's how it works. And then, the field underscore value is the field, the twig value. The field twig value, that's what this is. So, what I'm saying is, grab me this field, display my data without dbi-dice, and then put inside that beautiful monarchy that I just wrote. And that's what it's with. This is Clio Map, one to one. And there. Okay. So, how can I use this? So, when I first started doing this, I was using another type of leaving style guide. It was a style guide that you would create, you would copy and paste into your Drupal template, and then go from there. So, then after that, I started using other stuff and all that. I came across the most applied, the guys from For Kitchen. It's a pretty awesome system. So, this is ready and open source, and you guys can download today. So, when you go home, or maybe outside, you guys can download this. This will be a Drupal theme. You throw inside the Drupal 8 theme folder. You run your NPM, your golf pass, and then you will create the pedal lab, everything for you, and it works. So, you guys can read the documentation how to install, and you've got it working. So, this is awesome. So, I start working with these guys for Kitchen and stuff. I downloaded that, and then I had this whole bunch of ideas and stuff. And I think some of you guys have heard about Main Spring. Aidan Foster, a good friend of Aidan, that just had a baby on Tuesday, so he's not here. He created this Main Spring, which I've been using for the past few years, I think, with him, and I helped him collaborate a little bit. So, I convinced him to move from hologram living style guide into pedal lab. So, what we did is we forked Emulsify, got all the Main Spring stuff into Emulsify, changed a bunch of stuff, and then we came back. So, for us, I was using that, then Alex asked me to join their fork. So, when home at night we got together, we had an idea to redo everything. Oh, it's not there, right? No. It's how you do it. Oh, okay. Just talk. Just talk. Okay. So, we got to build this, and then we built this thing called Ergo, and it's basically a system based on all this that we are doing, but it's in-house sort of a thing. So, I didn't want to go. Yeah, so we've taken, you know, we did some work with Hayden and looked at some ways to improve it, and then we had our own take on it and started experimenting with it. And as a proof of concept, we were able to use it on a recent project where we didn't get final designs and no real specifications until late in the game, and we had to have a way to be on our feet and modular and get this thing going to a sustainable point so that once we have the pieces we need to make sure we can complete on time, this was the road that we went using pattern art, and from that we took some learnings and the way that we approached it that we're now in the midst of working to make it better and stronger. Anything else you want to know? I'm not sure. Have you ever moved that page? There's nothing else. The Ergo page? What happened? There's nothing else. Okay, Ergo page. Okay, awesome. So, enough talk. Demo time. Let's hope I don't disappoint business cat here. All right. So, to help make things hopefully smooth, I have pattern lab already running, and I'm going to walk you through having a new component called action similar to some of the ones we've seen and show what it's like without styling, how pattern lab reacts when we start adding styling and updates in real time, and then getting into Drupal and how adding a paragraph can then tie into the component similar to how it was described here. So, business cat, you need to go. Okay. So, this here is an example of a little more complex call to action. Some of the things around the methodology that started in mainspring, and we've inherited, is the use of BEM classes, and it's to help organize and reduce the amount of descriptions on any given item so that at any point in the clean DOM that we output, you know exactly what div, what span belongs to what, and to prevent collisions of styles because everything is so isolated that you're going to reduce any chance of overflow or, you know, regressions, which are, you know, you get a bigger team, you work on a big project in different parts, that can crop up, and this helps to avoid that by just segmenting everything as much as possible. So, in this example, this is an organism. It's going to have many parts to it, as you can see from the example here. And we have a space for another component, which is an image, and although an image could be just an image line, there are some efficiencies to having an atom, one of the simplest components, with a couple options that we can pass along. Maybe we want it to be full width. Maybe we don't, we want to apply a different effect. It gives us the flexibility to still have simple tags without much effort of managing them from component to component. As well, we have a section to show some icons along with the image, and then for the standard kind of call-to-action part, to have a lead-in, some body text, a button, and then the testimonial component that Pierre was showing you before, a way to include that and output the component. So with the data model, similar to the testimonial for the call-to-action, we have some configuration and passing along additional data. And the whole point of the data modeling while we're working on the components is we know this is going to be in Drupal. So as much as possible, we're thinking, how is this going to work in Drupal? How can we make sure that the fields and all of the paragraphs or content fields, how do I get that to this and make sense and, you know, not just be MS. So we spend a lot of time on this and making sure that what we're doing with the component is going to be able to tie into Drupal. So let's, you know, get up pattern lab. Did I let business cat down? No, there we go. Okay. So here's an example of that component with the configuration in place. And as you can see, it's not styled, but it gives us the DOM, outputs it, gives us a chance to see right away, you know, what we're working with. And then we choose to go and update the styling over my styles for the testimonial and bring over my styles for the call to action. And with this in place, without a typo, saving, pattern lab is going to inject and load the CSS without even a page refresh. So some of the supporting tools under pattern lab and the Drupal pattern lab specifically is browser sync. And how many of you have used browser sync? Okay. So it's a super efficient tool that lets you run multiple devices with one preview at a time and go up and down. But for efficiencies of building, inject CSS real time so you can tweak away and get things just right without having to do anything special. And some of the other bonus features easily allow you to test responsiveness and you have a fun little disco mode. I don't know where to use that, but it's a good test for your page. Will that survive? A crazy user resizing? Yeah. Yeah, it will. Exactly. So it's a monkey test and it's very handy to just catch those. You watch it and oh, there's that one resolution. Let's find out where that is and start tweaking with it. All right. So now we'll jump into Drupal. And in Drupal, we set up a call to action paragraph. So to satisfy the data model and the things that I'm expecting this reusable component to work with in the paragraph, I have a lead-in for the title, the body, a button, an icon group, an image, and then as well as the testimonial fields. Usually we build this separate way because the component is a component. So it comes from a testimonial, comes from a paragraph by itself. But we merge this together in order for the demo. Yeah, so we could have this as one of those entity reference fields and be pulling a testimony paragraph just as easily. You have that flexibility and there's a level where you have to start saying enough is enough so there is some considerations on how deep you want to go. But for the sake of the demo to show everything here, we have everything straightforward on the one paragraph type. And then as well when we're building these, the reason why we start using paragraphs instead of just having one big content type that starts getting bigger and bigger is using it from different content types that may or may not need it. But being logical on how we break out the individual fields and giving them some logical breakdown that we're not just throwing every field to the client at all times. So they have a chance to go and work through the different content types as they're building things out. So for the sake of the demo I have a simple content type with a paragraph injected and this is what Drupal is going to give me when I haven't done anything. So I have the paragraph set up, I have all the fields coming to the Drupal template but Drupal is just going to put it out until you put styling or decide how you want to effect the template you're just going to get what it gives you. So from there is where we have a chance to pull in the component similar to what Pierre displayed. So like the testimonial example this gives us a chance to set up all of the mappings from Drupal into PatternLab and anyone familiar with JSON which I'm going to imagine a good chunk of you are it's a very easy way to look at the data and make sure that this field is being this field sent along. And some of the fields in this case we're not always sending the field value. An example is this icon field that we're actually in this case passing an array and that's another component or another view and we can wrap a component around that if we want for the sake of the demo I just let Drupal put its diviitis through but in this case it's not a single field, it's an array of entities and we can work with them or let Drupal do its thing. You have complete flexibility over how to change the final output and with all of this data is being sent across to the organism that we worked on. Now if we take a look and if everything refresh there we go. So with that this is now in Drupal pulling the component in and all the benefits and what we've built out in the components are now reusable anywhere across the site. Now I mentioned having a paragraph inside a paragraph just because you want to use different components it can get overwhelming and you have to really think about am I just creating too many components now and am I overdoing it or too many components in components and even making a component and you want to say I want to have two different styles and it's going to be this style, this style but I'll just keep monitoring one twig file now for a component and it becomes unmanageable so there's a lot of thought that has to go into the structure of all of this and still remember you're going back to Drupal for our sakes we're tying as closely as possible in Drupal so it's really fine tuning how deep we go with everything. Alright and that's the end of our presentation if you have any questions feel free, we're happy to answer them. Questions anyone? Everyone's too scared? Yes, so as you guys know in Drupal 8 we have our configuration files what we call the config files so every time an entity or anything that's changed in Drupal that is not content it creates this file so we're just starting to talk into it config files it's very powerful but it's very complicated to manage so we are approaching it two ways do you guys remember futures module from Drupal 7 it got rewritten in Drupal 8 and it exports the config file, creates a .info and .module file and then you can install that module and it will create your config and everything it works for most of it but I don't like because it's one more module that's going to be installed let's install a module if I don't have to even if it's for that so one approach that we are exploring and everything is to identify the config files that are being changed and then wrapping up with our components so usability wise what we would do is we have our testimonial components our testimonial components we have the static files CSS and all that stuff that I showed and then we would have a folder with config files then we can manually drop that into the Drupal config files big file and then just then draft CIM and then it will create everything we are also exploring an automated way because what we are doing is the idea of components is to create a repo of components and that repo also would have our config files and then we would create a script so that it would install our components in our config files from our GitHub account or whatever you are doing so that's the idea do you know how easy it is by the way to take files? there are many ways so one way if you are going to do manually the best is keep your coding to get and then as soon as you get started with that would be that's how I did myself I have all my config files everything I do draft CEX which is export as soon as you export Git will tell you what has changed and that is the best way because you will see new files being created so for each field there will be a file but if that field is being injected into a content type there will be a change into the content type itself and then there is a change to the default display not default sorry the display there will be change on the system global file so what I would recommend is to do that track and get and then it will tell you exactly and then as you start working more on that you will feel more comfortable and you understand what has been changed but also just to do a search on for config files managing and you will see a lot of smart people are trying many different things in there it's pretty cool just to mention when you do draft CEX you can also do a dash dash add and it will automatically add it to your Git as in like your you mentioned it will add to the track file so like you confirm it and it will automatically add it right there just goes out we can still see it all okay so Git so draft CEX dash dash add so there you go thank you so any other questions come on you guys have questions yes that's right yeah I came across that many times it's sort of a weird like in the elite and you state this ghost data in there right early days of a triple I had a bet we've been doing some stuff and with the latest one we are 3.1 3.4 some kind of 3.7 3.7 so I think the 3.6 and 3.7 I had to do that and I didn't get that problem so I think it has been fixed or something has changed also paragraph had a release so I think it was an issue with paragraph and I think it has been fixed but yeah I've seen this problem in the ghost data so lucky we identified that pretty quick on our local computer and then we were able to go after delete the data first and then delete the paragraph so yeah that's a good point so there's one more benefit to an approach like components of pattern lab specifically using twig in this case is if for some reason we need to do a standalone app using Node.js there's interpreters to pick up the twig so that we can start injecting our components into a standalone app away from the Drupal website we're building potentially so that all of the components we're building for the website are immediately transferable and able to render through JSON data on a Node.js app so it gives you some flexibility in yes we're still aiming to build and hide this in the Drupal but we're not locked into only having to render this in Drupal so there's a lot of flexibility with this kind of approach that we didn't have when you build a regular Drupal theme yeah we do plan to at some point but it's just a different methodology of the same tools like we are not again reinventing the wheel because we are leveraging the work that they've already provided and we're just trying to get an angle of what works best that we could then distribute and be meaningful because to get it up to snuff there's a lot of work to make sure we have all the documentation it's clear and concise and that is supported enough for the community so the most apply on the main screen so the difference between the two is going to be this so when I first start migrating the forking and most apply in the main screen so main screen was built by Aden and uses them and smack folder structure and main convention which is the same one you saw we do M for molecule dash component underscore underscore because it's the next level down and then there is a alteration and that kind of stuff so the difference between most apply and main screen is going to be that so if you download main screen and you download most apply you will see the folder structure and the main convention is different but just because we decide to do that another thing is most apply is using a lot of npm stuff using a lot of npm stuff and main screen use a lot of bulk so that's the difference and with our tool basically what we decide to do is to change not only the front end but we are doing bigger stuff for back end as well so we are doing a whole bigger thing and working more on main convention because once you go deeper into componentization you got to really think about like Homer said be careful how your main things how you are doing your components also following the structure of variables and names and other stuff so any more questions? One thing I wanted to add on that we have a pretty strong relationship with both four kitchens and also with 8-concept so there is not a case where we just close our code and just start reading the fact that there is a quite strong relationship so while we work that over we work on that so I think that some of the work back in but that's kind of we are at a stage where we can increase it where we feel like it's only that we can comfortably reduce it and set that feedback so I can let it deal with it Yeah Aiden has been a big help and again we also reciprocated to get mainstream further along Do you have a question? I have a question What does that say the question? I'm getting a little bit of that It's kind of like this Everything is something that we can Yeah Again this is why this slide is here You have to strategically look at how I can use things in a reusable way without just floating the slide and having the same problem so it's very tactical and you have to play around with it and screw up and fix it and find the balance What we are finding is the more reusable we are trying to make we are getting a little bit more bits wrapping around but if you go back we get a problem with the was dibs, dibs, dibs fields main, few, underscore and field of fields so was dibs just in there because the idea of a dropper was well if a designer actually rocks something in here they have an active dibs so that was the idea so with this system you are doing more consciousness even if you are getting that tree down there is a reason you are going so you can start going up and see what's going on It's also kind of like the sort of business value oriented where it's focused on the data model it's focused on the structure of the content for us it's focused on the example you showed it was like panel, panel, panel, panel, panel, panel that's what the meaning was to the actual business value that's correct it's an excessive class usage like bootstrap themes and that sort of thing where there's just class, class, class and you're like what the hell is this you have no way to isolate no I know exactly what this should be doing and if it's not doing something I can easily target and adjust so that's another aspect that the band is not definitely on bootstrap so yeah it's super new we are figuring out as we go questions any questions I love that sometimes I put it on my back screen and just keep watching so yeah so if you guys want to try so I am part of a lot of places and people that are doing that so like I said the most of them are doing a lot of stuff so I'm helping them out I'm part of the main spring as well paragraph you know join the paragraph issue queue and stuff you will see there's some really cool stuff coming down the road in there that is just going to be amazing paragraph is just starting if we get together as backend developer and stuff all that as well it's going to be even better if you go look at the road map it's going to be freaking awesome Drupal pattern lab I will put the link after our presentation and stuff but there is some huge stuff going on too so we basically forked Drupal pattern lab Drupal from pattern lab into another Drupal and the guys from most of fire are taking care of that and we have fixed a bunch of stuff as well in there and the road map is huge and we are planning a lot a lot of big things in there so there is a community going and that definitely will get better an idea of one of the issues that I want to tackle is how we had the intermediary JSON like Drupal to pattern lab they are looking at a way of maybe solving that and going straight to pattern lab whereas like preprocessors we set up that structure there maybe and it's consistent config base potentially and you skip that extra step of having to then link one to one map one to one and that would be awesome because now we can create our classes our variables into twig and then a magic matches to Drupal the cool thing is this let me just give the last one in here so I was working for a company and we were redesigning a Drupal site and then they totally fired the whole digital team got a new digital team and they decided that they weren't going to doing Drupal anymore they were going to build in October which is Laravel let's see a mess sort of a thing a lot of design was done a lot of stuff was done it was already created for Drupal so they saw how huge this thing was going to be and stuff so they decided and told us I ended up leaving but what they started doing is start building the whole thing into panel lab twig file and the guys from October said just give me the twig files and then we will be fine so now building with Drupal in mind and then ended up going to a October thing sounds good? thank you very much guys