 Hello everyone. Thank you very much for coming. Thank you very much for coming in general. It's been amazing. Like the energy in the room is so freaking awesome. So anyways, I'm gonna switch from organizing this to speaking. So hope I can do a good job. If not, Homer's gonna pick up my slack in here, which probably will anyway. He always does. So yeah, so we are going to be talking today about achieving reusability through Componentization. So I don't know if some of you guys probably went to Drupal North 2017 in Ottawa. So Homer and I did a talk about practical componentization. Basically, a few years ago we were sold on this idea of let's make this component thing and then we never have to redo it again. And we started and it was really cool at the beginning, but then we quickly realized that it wasn't fully true. Basically, the reusability, it wasn't coming just by componentizing our workflow and our system. So let me ask you, how many people in here have done or are doing componentization for front-end in Drupal? One in there, two, three, four. Okay, quite a bit. How many of you have heard about it? Okay, that's awesome. So this talking here is the next level from 2017. So if you guys kind of get a little bit lost because we're going to be talking more about concept than diving into code. So if you guys get a little bit lost, when you get home, kind of watch the 2017 one at Drupal North YouTube account and then watch this one again and then things will start making more sense. And this is the one we have. So basically from this talking here, the idea is to share the vision that we had initially and what we were trying to achieve. And since last talk, we learned a lot and our idea is to share with you. There's a lot of answers that we don't have yet because it's just a learning process and everything. But one thing we have is the vision and the vision to achieve reusability. Some of you may be heard Dries talking about that when the day first started Drupal, it was all focused on the back-end. And it's getting better but it's still ugly because they were focusing on the back-end. Which makes a lot of sense because now we have a solid product with a very ugly front-end, but we developers know that. So now we can start improving this front-end and that's what we're trying to achieve from this talk. So my name is Pierre Marceau. I am a technical architect and front-end developer. Therefore, I live and breathe Drupal. I've been doing it for quite a few years, started back in 4.7. I am also one of the organizers for Drupal TO. So it's our monthly meet-up in Toronto. So if you guys want to join or speak, please contact me. We meet monthly. Like I said, I love front-end and I live and breathe that stuff. And I'm Sean Homer. I go by Homer because of the second Sean in the company. So I get confused when I introduce myself. It's kind of funny. I've done lots of speaking over the past decade. Some developer, some non. So I love front-end, a lot of the tools and the initiatives around therefore when pushing for componentization and just improving front-end experience with developers has been a big push for me. And I'm writing a book for 12 years. It's going to be done one day. Awesome. So let's get started. So why this talk was because we were sold on an idea of a componentization equals reusability. So now we want to share with you what we discovered and how we can solve a few problems And how we go from here. So that's the idea from this talk. We're going to be talking about framework in libraries and standards Because that's the whole idea of supporting this system, establishing a set of Architectural standards, making structural decisions at component level, Packing components across different projects, which is the main focus of this. So if we can't reuse, if we can't pack it, basically we are not achieving reusability. Leveraging tools and streamlining workflow. So that's what we're going to be talking in here. Okay. So in order to do what we are trying to do, we have to follow standards. We have to have a vision in order to do this. Because you can't, if you don't have a vision, if you don't have standards, You can't pass that to other developers and they won't understand. Then we go back to chaos, building site and the building site and the building site Rather than reusing. So we have basically divided into three parts in here. So methodology. So who have heard here about atomic design? Okay. Awesome. So it's a methodology for segregating and the grouping components On a way that it's easier to understand. It was created by this guy called Brad Frost And he's a designer and he went back to his high school days And grabbed the chemistry analogy. So atoms, molecules and organisms. So very little to a big organism. So we decided to take this methodology. We had to make a few changes in order to work with Drupal because we are mainly using this for Drupal Which technically we don't have to but we are. So that's what we are doing. So we grab atomic design and the change and adapt for our company. So you guys can use some other one. As long as you have this standard. And the vision is keep this standard. So pattern lab. Pattern lab is the living style guide that we use. So why did we choose pattern lab? Pattern lab uses twig. Twig is using Drupal. A lot of other living style guides. So for example if you go rb and d and some other stuff. What they do is they build their stuff, they grab their components And they create a library. Which technically you don't really use. It's just a visual library. We wanted to build a visual library That actually is the code that you're running on the front end as well. So pattern lab allows to do that. There is another one called ks. That allows to do that as well. So our living style guide. So we grab that as well and adapt to our workflow. And then Drupal. Drupal is Drupal. It's what is powering the whole thing. And we divide it into three. Because here's the thing. We have a methodology. We have pattern lab which is our living style guide. And if we are starting a site, we can have our front end developer's building. The front end. And we can have our back end building Drupal. Totally separated. So that is what we are trying to achieve. Which is, by the way, is working really, really good in that area. We can fully, today, there's a lot of times that we have a full team building the front end. And they don't even talk to the back end. And then we just merge together. But of course, not really talking, but we have the vision and the standards. And that's why it starts working. So here's a little list of stuff with the atomic design. So the basis of component coupling. Draft the better suited working with Drupal. Drupal stocked with the proper standards. And then back it up. So I'm not going to read through just pretty much what I just talking here before. So that's you. Alright, so architectural standards. A video which I'll loop through again. But kind of showcasing when you don't have standards. And you start doing components. And you start building components for this and that. And you think, hey, I'll make a component for everything. It doesn't work out too well in the end. Especially when the idea of reusability comes back into play. Components get complex or they're too generic and not useful to reuse. And you can have a lot of access code that then makes it impossible or very confusing to maintain. And that is instant tech debt that probably is not going to be resolved in that project. And have to be dealt with at some point. And then if you want to take it to a new project, you might be creating from scratch. So watching the video again, you see all these attributes that we're trying to serve. And for a corralzel instead of having an easy way to send different types, we have a different component for each type of corralzel item. It gets very confusing and very convoluted for people to know how to use it. So having architectural standards. The key things that we've been focusing on around this is having those established component types and knowing how they work together. You know, atomic design is a great concept, but it's very lightweight. And whether you use atomic design or not, you're going to start off with the basis of how your components work. But you have to get really nitty-gritty with each of them to say, this is going to work this way. It's going to play with this kind. And this one is going to manage that. And you have to start building a clear vision of how these all work together so that as developers come on board and start working with new projects, they know how to access whole components that have been built and build new ones all along the same maps. The other big thing is naming conventions. We leverage between Patterlab and atomic design, BEM, SMAC, kind of joining, I guess. And we adhere to names all over the place so that it's consistent. Again, helping anyone who reads it knows this is going to match this type of component, this type of component. A file structure also to make things as easy as possible for developers to go in and know these components, match these Drupal templates, and avoid some of the confusion or loopback to say, what is this, what is this doing. And lastly, as you're building these things, even going down to variables in style to be aware of, you know, if I take this component out of this project, is it actually going to run in the next one? Thinking about these things as you work. So with the different component types, again, we are based on atomic design, so we have a clear set of atom molecules, organisms, and then we've taken it a step further in using layouts to match things like Drupal nodes and content types, and then mockups so that as much as possible we're building all these components potentially away from Drupal to mimic a real page and make sure once it goes to Drupal, all the components are going to play well together. And having a set of best practices in place so that as we're getting created there's some documentation or something to back it up on what the developers are working with. And naming dimensions. From these screenshots you see that there's a very common theme of the atomic typing and the dashed or camel cased variable names and to identify this component anywhere across the project includes documentation. And names with components gets to be very complicated as well. You can spend a lot of time, a lot of stress over it. And in one respect, you want to keep it very contextual so that as you bring it to a new project, the name makes sense. It wasn't something like the top nav doesn't help. But the other thing is sometimes when your components are going to grow and change as you learn more and better ways to improve them that if the name isn't working you might want to change it, you know. And to understand that it's okay but do what you can and just try not to stress too much. And when it comes to file structure because we are working with this concept that is focused around essentially a Drupal theme to manage the components, serve the style guide but then tie right back into Drupal we want an easy way to have the component structure to match the template structure so that as we're working with Drupal templates you find the component name and you go right to the component folder you know one to one kind of what you're working with is less confusion as well as the assets and other files right off the theme is very clear and lightweight so that devs are hunting in subfolders and trying to guess where did that person put this. And one thing here just in this year we worked with a team and they never built Drupal before so the idea was they approached us as building Drupal and they would have built the front end and suddenly the deadline got really short and they had to start right away so the approach we took was okay how about you guys build the front end and then we start working together and then building the back end and attaching together because the company the way they were doing the local setup and stuff they couldn't get Drupal installed right away so what we did is we had our repo we pushed to them they installed the pattern hub and then they started so these guys never touched Drupal so basically we had a daily stand up in the morning we had our scope what we were going to get done at that strength and then we would talk to their front end and they would say okay we are building this how should they build because we had the standards they start following our standards they start following our samples components that we have it's like you guys were seeing it before in here so they were working out of the components folder on top in there and that is inside a Drupal theme so these guys start building everything and we worked on the project for about a month or so I think and then that being a very large project and to this day these guys don't have a Drupal installed on their site yet on their computer it was insane it was the first time we've done that and it worked really really well so what is that proving it's proving that finding Drupal developers are getting harder but finding really good front end developers is not that hard and they are good on what they do so why we have to force Drupal into these guys into the daily it's from end so let's get them to build it's a component it's a photo that floats with a title and a description why you need to know that this is coming from a node and it has field underscore value blah blah blah blah Drupal node PS thing no you don't need to you don't need now all they need to know is what do you need to make when we go off the island using Drupal they don't make things complicated if you go to one of those template sites that you buy and then you look the markup most a lot of them are super clean markup and the reason why is because they don't have this that from technical debt from Drupal or from anything else so they are building super clean and that's the whole idea so by structuring in a way that we can now extract that from Drupal now we can have many teams working throughout that and not need to know so maybe on a very large project all you need is two Drupal guys and maybe five and people doing that and that's what we are trying right and when it comes back to keeping reusability in mind at first we were building things very isolated and that was going to be great I'm going to reuse it and again as I mentioned even down to some of the style variables which I'm showing in the sample video here we weren't thinking head we were like this is a great component okay now how do I bring you to the next project even something as simple as making sure you establish how the styles are going to work how some of the atoms are going to carry on so that when you spin up the next project you can depend on a certain amount of work carried over that's where we had to get to before we were just copying the site and spinning it up thinking everything was going to be great as soon as you remove a couple things you don't want and then it breaks so building anything new now is keeping these things in mind and these standards to say I know at some point this is probably going to be reused so how can I keep it simple keep it focused to what that component style is but in that small percentage usually is more unicorns exist and when it comes to componentization you're going to kill yourself trying to satisfy components in unicorns right so sometimes you have a crazy design and you have something that is possibly used on one page in the site you're reused will make it that perfect component because it might never have any value right and you drive yourself nuts for a couple days building it and it only gets used once so there's potentially no visibility in a component and you have to be thinking and aware of this as you go so back to the know-how and building components it really comes down to having so many standards in place and does that mean you have everything and all your standards ready to go when you start your next project? probably not, we've been working at it and we're slowly building up having more solidified standards that make sense and we've definitely failed along the way pretty much every day we're working or doing something new or realizing that why did we use this and making it too confusing even to explain in documentation well that's a clear sign that we should clean something up make it simple, make it clear for the developers to keep an eye on so now I'm going to go into a bit of the specific component types and our take on how we had to start putting some of these standards in practice if you're not using atomic design or you have your own take on it some of these would be a little more abstract for you but you're going to start with something that's smaller or medium big of some sort in your design library that you have to play with and you have to simply establish whatever that is atomic design or not so when it comes to admins for us we've come to the philosophy that they really should only do one thing wrong which is very similar to Brad Frost's methodology and we define them a little more that the HTML might look a little more complex but it's got a lot of fallbacks and things to make sure that all the different options and stuff to make sure there's a very clean simple don element at the end of it it's never including another component it's pretty rich and has some options but you can't override things there's no blocks, it's just a truly simple component when we start moving up to the molecule level this is kind of a gray area because between a molecule and an organism it gets wishy-washy sometimes and we've had to establish the fact that you're only going to include a couple of components but here is now where you start to do some interactivity behavior or JS potential but the DOM's, you know, it's not crazy, it's bigger than an atom for sure and depending on the use case it might be a little more rigid it might be a little flexible but it's still small and it's not going to contain anything too large that ends up on the page then when we move to organisms this one was a big learning curve it's back to the earlier video where we had the carousel and there's all these different types we used it, we were trying to send so much data to an organism that the organism would do everything oh, if we just give all the data we can build all the molecules and all the atoms from the organism and it became this monstrosity that was very hard to manage and when it came to using some more layout style organisms or the carousel again, the different slide types you're stuck you have all these variations, developers have to remember which one, which twin do I call and all these complicated things but we've moved to a way that organisms are more layout focused and we prep and passing actual ready to go components and it's simply managing how they fit on the page and make sure it plays well with other components on the page level so it simplified a lot of things for us because these are typically created for specific reasons we have less fallback code here because they have a dedicated purpose and they're blank whereas the smaller components might have more optional features that I show so then moving on to more of the Drupal layer that we've been working on with our components is layouts and this is where we have node or content type level and similar in a way as we're in an organism but it has no behavior an organism would have potentially the most behavior because it's managing all of its parts but the layout has almost no style, no behavior and it has extended parts of blocks so that if you want to embed a page node type like this and you're going to have another content type where all your overriding is a content block you're not going to recreate all this layout because it only serves the purpose to keep the head of your footer and it keeps things more simplified on this level for Drupal and mockups so when we started components we do a lot of organisms, molecules and think hey, it looks great let's put it in Drupal I'll put it in Drupal, it looks like shit so we had to respect the fact that mockups are essential in building out these components together because as soon as you want the home page and just set up components again you just work on the organism itself it looks great, put it with other organisms so wait a minute padding, margins, these things just don't fit well or get a responsiveness similar conditions so mockups became an essential part of our process and standards to make sure that we are working as a building these all the way from the live page level because you just never know how it might get affected when you're focused too small actually, let me just so when it comes to the mockup looking at the code in there, you guys may think well, it takes a long time to build, but actually not really and it saves us a lot of time because we can get things approved if the site is really big a lot of UI guys look at the review sometimes they don't create the design and they say the front of the guys figure it out if we tie that in Drupal, it will take a long time if we are putting the mockup we can just push and say hey, what do you think? Oh, looks great go ahead so back to this here as you can see in there page content, joy, include so all this stuff in here from join below already has been written in the atom molecule in the organism level all we are doing on the mockup level is coping and pasting to the YAML file so at this point you can build a let's say that you built the header you have the cultural action you have your footer and you have your slideshow for example, your carousel all you are doing to build the mockup is you create your twig and then you start including that stuff which you see in here and that's it so within less than 30 minutes you are able to build a page what we can do to let's say we are having our stand up in the morning and then the client says wouldn't it be awesome if we could switch this to this and then our answer a lot of times is sure, we can do that if you prioritize, we can do that right after this call oh really, you can do that? Yeah, we can because now we are only dealing with static data into a YAML file so that's why it's very important and we found that out through this project working with this front-end team that wasn't doing Drupal they were building all these components looks really good when we put on a page in Drupal suddenly the patterns and everything was everywhere so then we went back to them and said hey, we really have to build the mockups suddenly when they start building the mockups we start going like this we were building a page within half a day and the pushing and the connecting to Drupal and the pushing to the content specialist to start adding content and then figuring out little bugs and all that stuff so it works really good and it's not as scary as it looks and then the last aspect of the component level kind of standards we've been focusing on is the Drupal side so as I was saying before when we were doing even layouts we were trying to shove everything into big huge data right and it just didn't make sense so this is the concept here where we include off of this for example a text component we prepare it and then pass that along to the actual bigger component so this big component deals with the layout where we get to pick and choose you know, oh there's no type, oh we're not going to use that we're going to use a different sub component to feed into it, we're not stuck to rewrite the organism now or the layout and say, oh we didn't think ahead we weren't thinking reusability we know that it's going to have something but we want to be able to switch it out where it makes sense ok, now to the big one how to package all this stuff and start reusing so this has been quite a challenge we had some bells and we had some winds and we're still working on it we have quite a bit of moving parts when it comes to this so prepping and exporting existing code so basically you start working on a website you are assigned to build a call to action or a summary of a news you get to a point where you look at that, it looks really good and you don't have that in your library yet which I will get into that then here so the component level is the pattern level it's the parts that the non-drupal the front end people are building which is markup and CSS that's it so when to export what we've been finding is the best time to export is the white label stage because as you saw before we are not every variable that we use in CSS it exists on the main site on the main theme so it doesn't break so when we export that we try to export our ways at the white label level so sometimes it doesn't work that way at the end so what we do is we go back a little bit and remove some of the specific branding from the client one thing we learned do not mix atoms molecules and organisms when you're packaging that if it's an organism keep it by itself even if it's very little code as soon as you start packaging a lot of stuff together you'll be seeing that the next site will be using all that and that is the thing small package only what it is how can we control all that so basically we use the markdown file with every single component which is basically the readme file so when we are building that we just start writing the variables that we are using to make the dependencies so for example you have a cultural action that depends on the photo on the image item so you just write down on your markdown and the next team when it's coming to reuse that they will see and start understanding what it is okay when it comes to the Drupal configuration so probably a lot of you guys are doing Drupal 8 Drupal 8 has the amazing configuration actually Drupal 8 is going to turn three years old can you guys imagine that? it's already three years so we have the config files which means that now we can export everything we can go manually there and grab every single file and export what we found is it's not the best but the futures module works really good and for some components for some sorry for paragraphs or for some entities when you choose the bundle you won't check every single box so when you're building it's good to kind of as you're building you start building your futures and I don't know how many of you guys have worked with futures module before on top of export so just update right? you create version 1.1, 1.2 or you keep beta when you're done you export the whole thing and it's a module when the Drupal exports a future when the futures module export the configuration it's a full module which means that now your back end guys can throw some pre-processing there you can put your template in there that will tie to your component, your pattern so one thing that we found and we exported a few components and we imported to another site what we discovered was some fields so let's say that you add an image field and then you call field underscore image you bring it to your new site, your new site already has a field underscore image it will have a conflict so what we decided to do is to prefix every field with the component name so you're having a call to action so it's field underscore cta underscore image field underscore cta description so that way now that specific field belongs to that cta only so that's what we're doing so it's a great way for you guys to not have conflicts later on you can bring it to any site when the building it kind of a hit or miss but we find that building as we go is the best but I'll be I can't all the time it's just because sometimes we're really busy so we try to export all the time but we can't so doing after we always kind of have to remember all the fields that we did and everything so if you do have the time add that right away because we'll save your time later okay so now that we have everything exported which if you think about what means export right so futures will have a modules package and then your component it's just a folder with four or five files that's it right so how can we now structure this in a way that we can go back or tell someone hey using this component here for this slide show you're building on this site so basically gets your friend so what we decide to do is to put everything in the repo and then label and again it goes back to the vision and standards so using standards for your naming so in our case the code name for our project for our theme it's called Ergo so what we decide to do is our repo is called Ergo the atomic name the component name and the type and here's an example so Ergo O for organism culture action F-E for futures so this is your futures module and even if you're not doing a full component and stuff this is still really good and we worked with say university they are doing componentization but in a little bit kind of a different way and they are keeping everything in the futures module which is very interesting they are keeping their CSS their markup and everything in the futures module and it's been working really really good for them so you guys can try that and finally Ergo all culture action C-P which is the component so when we are doing that as well what we do is let me go back to here we also like Homer was saying we start with one type of component one pattern one culture action that has an image, a title description and one button suddenly we built one that the designer had a whole different idea so what we do is we build that one and then we just tag into a different version in our get so now we have two variations of that that we can go back and pull that into our new project okay okay so how to import this thing so when we first started we started doing manually and sometimes we still do so basically what does manually means so that I will go into my repo and I will download the files and then I will go into my Drupal site, I will get the futures module and then drop into the futures module folder in my custom Drupal folder I will get my pattern go into my theme and then drop into let me go back in here where is this structure here and in here and then drop into your components folder, get your template if it's not in your futures module, drop into the templates folder and then run gulp and this should work so and that's the manually way of doing this so the other way that we've been exploring quite a bit and it's still learning is using Composer so we are already using Composer to manage Drupal so we are installing Drupal we are installing our contrary modules everything via Composer we don't push modules to the server anymore we let the server build the modules via Composer so now your repo is getting really small contribute stuff it's not in the repo anymore so we are doing that with our theme as well so we are not keeping our CSS in the repo anymore we let the server build and then Homer the stuff sends to the repo I bring down and that gets built on my computer at that time Composer is awesome Composer the last time we had that security issue with Drupal that we had to update the site right away because it was just a few files all we had to do is to update our Composer file and only two files were changing so then we pushed to the repo and then the server built and that was it so very fast so it's a really good way so what we are doing is using Composer adding these components that we have so for example you need a cultural action component we add to our Composer file and then we'll pull the Drupal Futures module and your component and put it into the right place because you can set on your Composer file so it works really good if you guys go online and start searching for that you will see the power of it last aspect of this I'm not going into things like gold and Drupal which are modules which help you get a step ahead with all of these tools but something a little more basic that when you have all those in place and you go project to project and then you think of local environments now there is land build of Drupal VM so all these different ways of doing things that a local developer we add all these component way of doing things and these new ways of building things just starts to become a heck so we're working towards having a project level CLI and scaffolding tool that is very straight forward set of commands that allows them to do some Drupal stuff do some stuff with the SSH whether it's land build or Drupal VM and then do some theme stuff but keep it very simple and consistent like documentation so as I start to go project to project they have a dependable tool it's always there and it saves them time from having to create components especially because as we're building these standards now for them to manually create these files and make sure it's using the right set up each timeline for each type of component it gets very convoluted so these tools just get them a step ahead without any extra effort so we use it to help with git management do a dev branch, do a local branch do with git conflicts we help streamline that when it comes to the tool you typically be running a certain subset of gulp things but what I want to go all the way into the theme folder or remember which theme folder you just do everything in the project route nice and simple and beyond running the gulp commands there's some helper theme commands that do things like rebuild node and other little gauntresses that just save time and effort and the scabbling as well just to make sure that they're on a couple commands they get the new components in the right place with the right themes ready to go and even for some of the Drupal stuff as I say we're starting the transition to Lando and it doesn't always work with the Lando command the way you want so we added some simple SSH commands to go straight in, do what we need pretty hands off and this is a sample again of the pre-generated code so with my CLI you just punch into the type of component in this case it's a molecule I gave it a name, NAVTOP I typed it as a regular string with caps, whatever I wanted gives me the proper names, camel case dashed all ready to go, all templated and give me the best results for the type of component alright so that's up to the questions and answers now I'm hoping somebody has some in case you're wondering who made all those sexy screenshots, that was all me that's right any question on this crazy stuff it's more a concept so it was everybody too scared there we go in Drupal 7 you said yeah so the question was what we can use with Composer in Drupal 7 and using these components I heard that there is some they are porting back Composer into Drupal 7 right, I think I haven't done Drupal 7 in like 2 years or more so I have no idea but I heard that it is doing you could but I wouldn't really recommend I to be honest start doing componentization as soon as Drupal 8 came out and the reason why is because the templates now are clean and really well built using Twig with the PHP templates that we had before that thing is a nightmare so as you saw in some of these slides to pass data from a template to the component we have to have a more clean way and in Drupal 7 I don't think it would be that clean but I heard that there are some people doing I don't think it will really take off because we are 3 years into Drupal 8, it's getting pretty solid in another maybe 2 years I think we are Drupal 9 and Drupal 7 will be dropped thank you for the question anything else? any other questions? come on don't be scared yes related to bundling with the concept of componentization previously years back all your CSS in one place all your CSS in one place sort of separated by type now we want to separate by component have component, have all the CSS JavaScript but for performance reasons you still don't want to ship 100 different CSS files to the browser but ideally let's say if you have one complex site where some pages rely on different components that are not really used elsewhere with a little bit more heavier CSS in JavaScript you also want to compile everything into a single CSS file do you have any standards or tricks for figuring out oh this should be a vendor like a common file this should be a separate file can you repeat the question? sorry the question is around whether or not you can separate some of the assets that come with all these components if you get a bunch together versus just giving everything at once so there's definitely ways I mean inherently the systems are building and Gallup will eat up everything but there are ways to exclude and then using the attached library to individually specify or without too much effort extend Gallup and say I need a separate build process for the site maybe it has a single-page app that only works in mobile and you don't want that heavy payload on every site especially on desktop users so there are ways to get around it nothing too complex but there are ways but it comes to identifying the right solution for the site and not even just that because triple behaviors and then you have all these components sometimes auto running code you want to make sure that things aren't running unless the component exists and you know you're saving cycles wherever you can so there's a lot of performance considerations when the behaviors come in and to make sure that that's not just running well in our case so far we haven't seen we haven't separated much yet just because what we try to do is if your code gets bigger than 100 or 200 lines that means that your component is too big right? keep it clean so far it's working pretty good and we are not having performance issues or anything componentization basically when it gets through Drupal it gets cached everything Drupal 8 has an amazing caching system so far so good we haven't had any problems so thank you for the question go for it sometimes you might run into issues when some modules are being upgraded for example they may not work well with other modules so when Composer does all the updating automatically how can you avoid having those kind of problems can you help me? yes great question oh yeah the question so basically if Composer updates module automatic how can we then avoid conflicts and all that stuff so we went through that problem so basically initially when we were building our Composer file we would let just basically every single version on that minor version would be coming down the pipe and then we got into that problem so we wanted to update Drupal Core but then we updated everything then Fields Group had a bug and a broken bunch of stuff so that was the time for us that we said Composer you're great but we will have to tame you a little bit so what we do now we basically fix every single component to the version and if it's a dev version we lock to the commit so the only one that we leave that open is Drupal Core so that one will do so you can update that one so what does it do what it does is makes you mindful of what you're updating so you get one person within the company and they will say we have to update Drupal Core and we have now three modules that we have to update so that person will go to Drupal.org check the version check if there is any bugs if there is people reporting bugs and stuff if it feels good you go back to your Composer file and then you change from .5 to .6 Composer install and boom you install then you can run that tasks and everything if everything is good then you push to the server and build that for you in there that's how we're handling thank you and we've also done this on the theme level so we originally forked Emulsify and worked with Aiden Foster on the main spring where it was kind of using the pattern lab in a composerish way but it was just freeform so that from one project to the next our developers could have ended up with different pattern lab versions and some of them had bugs so we've been able to sort of corral that and as part of the theme have it as a composer dependency of a theme so that pattern lab is working well long version and we don't have to have any guess of whoops the next project the theme wasn't built because pattern lab has gone on something that we couldn't test in that instance yeah Composer is really powerful I've been following the community and all that stuff and that's the way it's really moving and that's the way Drupal Core is trying to ship now composer in core that you know that the composer that when we download Drupal Core you can't update itself right because that composer is in there you have to remove so your composer has to be out your vendors folder has to be out and then your Drupal folder has to be in here so the Drupal Core composer only updates contrib models doesn't update itself and then I just heard in the podcast that they are changing that and they are working towards having that composer update itself I don't know how they are going to do that but I heard they are doing so any other question I think we have five minutes or good so as I said as I mentioned we work for therefore we are a web agency in Toronto I am a technical architect in there and developer Homer is the same if you guys wanted to work on some of this crazy stuff in here we are always hiring so when I first started Alex approached me and said hey you know this crazy stuff you are doing how about we do together and he pays me to have fun he is gone right so he pays me if you have fun so if you guys are interested in that and would like to join the company get in touch with us if you don't want to join the company because we suck but you like what we are doing just join the Drupal Teo Meetup we always open like I said I live and breathe this and we always open to talk Homer is the same thing and reminding everyone so today we have the after party if you guys want to go in there we have a shower booth and the Pantheon we are giving $20 gift card for you guys to go there I went there yesterday for the first time it's called the rec room they have a VR thing in there that you put the backpack and you kill ghosts and stuff it's freaking awesome and you can have beer while you are doing that it's even awesomeer awesomeer awesomeer just stop by our booth our Pantheon and our partner and they got the gift card $20 in there and thank you very much