 All right, so I'm Kyle Lannaker and this is why is building components in Drupal so difficult? If you need the slides so you can't see on the projector, the tiny URL is on the board It's just tinyurl.com slash cat components and Yeah, like I said, I'm Kyle Lannaker. I'm senior type of architect at a company called proficient a little bit about me I've been doing Drupal since 2014 But about a year ago I moved from Asheville to from Chicago to Asheville Where I spent almost my time drinking some of the craft beers there or hiking trails and the move is relevant because I Remembered on the flight over here that airplanes eats are very small This is the first real time I've flown a distance since COVID and I did not enjoy remembering that So a little bit about proficient as high as the small 7,000 international Digital digital consultancy that you've never heard of So yeah, we're 7,000 person companies for across the globe if you can think of a technology We probably had a team for it and Drupal's one of those technologies So they've been very very kind and sponsored for me to be here and speak about what about components and I do believe we have a couple openings right now for developers fans and BA's on our Drupal team So if you're interested in that, try this out at proficient.com all right Baseline stuff name things is hard So we're gonna get started with what I think a component is what I think a component system is and what basic components system successful starting with components in My mind what is a component? Component store content. They don't store data That means that if a value has some use outside of being rendered on the front end Don't store it in a component, right? If it's a recipe ingredient if it's a song on a CD if it's a chapter in a book That's all data not stored in a component If you need to display it in a component use a reference and Bring it in for a day store from that to the etc as you need to render it so that that's a Key distinction because it means that components don't need to be functional with views or queryable And it really limits the use case for what you're going to be doing with components with thanks a lot simpler to build and Then kind of the standard stuff. There's standalone standalone module UI element They're expected to be used across many pages and content types and they can be embedded in other components authored as a standalone component Or a rendered program Trying to get my notes bigger here so I can actually read them All right And then I think one thing that might be possible sometimes is that the data structure or the data model for component is actually So highly structured content and in Drupal if you get if you pass the wrong data to a twig template It just blows up your site. So it's very important to acknowledge that getting your data structure right and getting your data types right as important when you're passing them to a component template and then We're gonna be working through an example here of a simple component, right? So this is simple side-by-side There's some text on the left. There's an image on the right and there's a link So we'll be referencing this as we make our way through the presentation Next one more important note. We are only talking about authorable components in this session So when you're talking about components You can talk about components that can be authored and are meant to build out to experience on site Or you could talk more internally about a component on an editing page in the admin interface And we're not going to talk about those because those are more Programmatically created maintained by the Drupal as a system and not really customized on a site-by-site project by project basis I think most of us probably are building authorable components not programmatic components by the back end So next up what is a component system? One component isn't much use we need a lot of components. So this is not showing up well But that's a pretend we're not developers and pretend we're in construction or something, right? And we're starting at a new job and they say we need a new battery for the drill Which shock would you want to buy a battery for the one that very clearly has a favorite brand? And you just need to go buy the red one at Home Depot or something or the one and there are circles here somewhere Yeah There we go the one that has three different brands this is a very simple illustration of the complexity that not having a system And cannot create right because it turns from a simple task of go buy a new battery to Which which drill needs a battery what size doesn't need to be what brand is it right and then Some suddenly something that should have been fast is something that could easily have a mistake made and cost even more time So back to being developers what is a component system a component system is not a design system as a very important distinction Design systems are built for an organization and they're organizational wide. They're usually meant to have a brand consistency across all the marketing channels and they're usually meant to be used in various different mediums right and they For success they actually require executive level sponsorship So your C level your VP level your director level etc. Without that to enforce Adoption of a design system is just going to fail But fortunately you can build a component system without executive level sponsorship You just need buying from the the owners or stakeholders of a site So a component system is not a design system A component system is also not simply a question of components because if you have ten components built differently That's not a system. That's just time components What a component system is is a question of components using common patterns. So Some example of the common aspects that you can find in components a lot of these you're gonna look like theming common access because they are because all of your components are a theme so Components are going to be used atomically or like I said laid out on the page and it's important to acknowledge that The the audience or the users of the component are not just developers They're not just your site visitors. It's also your content authors your designers and your stakeholders So really everybody that's interacting with the site in some way is an audience for your component system And then so now we're back to our example component when we're looking at this It looks like a simple enough component. But once you start getting into a system This turns into four separate atoms that we're building intimately and then two component-specific fields So our atoms break down to a higher or a description of link and media Then our component-specific fields are does the media go on the left or the right and Is there a background color? So it's not this other simple component can become deceiving complex, right? This is four fields or four for different. Yeah, it essentially looks like it's four fields But it's really four atoms and two fields And then diving in deeper Let's just look at the header in my experience a header is never simply just a text box There's typically a text box and then you need a display size But you also need the element size because authors want something to look like an h2 But they actually want to be an h3 or an h4 So typically when I build a header, it's not a sex box There's three additional fields which again just continues to add to the complexity of what a component system is and how you're building it And then you get into how you how do you actually use the component? So how is this authored right? Is this a left right left pattern that's enforced is it limited to three? In a row is it a listing is it three individual components placed on a page? There's a new component with a repeating field set and the answer is there is no wrong answer It depends on the site depends on the business it depends on who you're building Who you're building site for and really what the design said and that also adds the complexity because you want consistency in your component system if you're gonna say this is a left right left pattern and forced of three Then when you see that in other pages on other designs, you should also be following that That precedent so that when authors create something and know what to expect and that goes into Authors knowing what to expect in the creative page and then not being surprised that they can't do something or that they can't do something And that just enforces consistency for developers designers and authors right And then what makes a component system successful this gets into a lot of opinion based up if you disagree I'd be very interested to talk with you afterwards, but I'm hoping that most of us agree with this so First thing buy-in from all users of the site. So like I said, this is gonna be the designers the developers the stakeholders and the other business units for business People that are involved in the building of this site if one group doesn't buy in they can make implementation take longer More be more expensive or could simply outright fail right if your designers aren't on board with doing a component-based design That's gonna be catastrophic If your authors can't wrap their mind around how to offer Pages in a component-based system. They're not gonna create a good experience and if your developers don't have experience We don't want to build components. They're not going to build components So you really need buy-in from everybody that's gonna be touching the site and everybody that's gonna be using the site to be successful and Then you need to remember that for the lifetime of a site when you're building it That's a relatively small part of the total lifetime of site, right? You're building it for six months 12 months, maybe even 18 or 24, but sites live for somewhere between three to seven years So there's gonna be people that follow you there's gonna be people work on site after you So when you're building a component system, you're not building it for yourself Even though it is gonna make the initial build faster you're building it for the people are gonna follow you So the authors are gonna have to look at the site day today the marketers are gonna have to figure out how to make it Engaging for their audience or their visitors the business stakeholders that have business goals to achieve and then future designers and future developers We're gonna want to change change the site to Enhance or change the strategy to get more engagement So just remember you're building for the end user You're not building for today, and you're not building just to get the site done and then another Important aspect as we touched on consistent experience so the designs the author involvement across the board when you're Creating something you want to create it in the same way every time and if you're doing something different There should be a reason for it because if it's not consistent It makes it a lot harder to wrap your head around and to build a mental model of and to then Work in that system as well because if you can't identify what is the right way to do something The way you know how to do it and the way you know how to do it probably doesn't align with how somebody to pass it Or something the future is going to do it So then you have many different approaches to solving the same problem Another important aspect is lowering the barrier to entry and just acknowledging that there is a barrier to entry working on a site The first one is don't be clever if you have an option between being clever and choosing and doing something obvious Choose the obvious solution because being clever is hard to understand later For either future you or for somebody following you So it's a lot better just even if it's four or five or ten more lines of code Just do it the obvious way instead of the clever way. This is particularly painful in the JavaScript community they love their one liners and It can be a pain to dissect what they're doing later and then you sit along the same lines to use standard approaches over Drupalism because Drupalism require Drupal knowledge to work with successfully Whereas if you're using standard HTML standard Java script standard CSS approaches It's gonna be a lot easier for somebody with the last experience to come in and work in that component system successfully and then Actively address implicit as for institutional knowledge buildup So a good example of this is if I say we need to do acts on the site and you think oh this person can do this Can do this that is an example of implicit or institutional knowledge buildup They have something in their head that says I know how to do this work that you don't feel confident other people can do Which is problematic because it means if they leave or if they're busy then nobody can do that work so a big part of doing a component system successfully is addressing implicit knowledge buildup and Documenting it making it explicit or removing the need for that implicit knowledge by a changing approach So you want to address that as it pops up and it's going to be a thing where You recognize that is building up and then you address it and then it's going to start building up again Right, it's going to be a constant battle. It's not something you solve and then just let it be And next big thing is discoverability So in my opinion a living style guided is the requirement for a successful component system because if you require a Drupal a Drupal environment to discover your components that is too high a barrier of entry it might not be for developers It might not be for authors, but for business stakeholders and designers They are not going to go into Drupal and author component to see what options are available They just want to go to a site They want to be able to click around and they want to be able to understand the system. So We pretty much only a storybook in my company It as far as I think there are competitors the storybook as we were talking about there's Pat on that But I think that's pretty much lost market share at this point. I certainly haven't used it in a long time But I think there are some actual like competitors or alternatives the storybook in the job script world I'm just not worried what they are for those of her to Importantly when you are doing a living style guide, you have to represent 100% of authoring functionality If you don't have 100% of author functionality, what's going to happen is Your authors are eventually going to say well, I can do this in Drupal But I can't do it in a storybook So why would I go to storybook if Drupal is the source of truth that cannot reference for what can and cannot be done in your component system So you need to represent all functionality and limitations outside of Drupal So they actually trust your living style guide to be accurate so that when they go into Drupal They're going to get the same thing and have the same options This doesn't mean you have to replicate the authoring experience, right? You don't have to replicate this field is limited to five in the component Fields that might be something you just talking right like this field they'll accept one to five values And then one of the things that we found to be most beneficial is making the easiest development path Being through the style guide for front-end developers because it means that you're always going to have an accurate representation What the component is if it was developed the storybook first and then moved into Drupal Whereas if you build it in Drupal, then you have to move to storybook and that's kind of optional, right? If it works in Drupal then it works on the site and they can author it and they can you can launch it You can come back and do storybook later But if you're looking for a hundred percent accurate storybook then it needs to be in storybook too So going storybook to Drupal makes it mandatory whereas Drupal a storybook Under a time point you're not going to do the storybook part and if it's a little your component system is going to fall apart Now what you'll notice in all these items is a lack of Technology preferences or technology prescriptions and a lack of technical criteria because the success of a component system Doesn't really depend on the technology or the technical approach It's a lot more about having the system having good standards and just sticking to them And then obviously the success of your team is going to be somewhat dependent on the scalability It's a technical approach you take, but that's going to be more relevant to the problem You're trying to solve then having a component system Great, so that's roughly what a component system is and what I think is and what and what I think it needs to be Successful now on to you want a component system. What do you do then? So there's two big considerations to make One is how you're going to be using your components and two is going to be component architectures So we're going to walk through both of them starting with component usage And we'll start with the coupled approach. So this is a traditional Drupal site It's going to be built in and using Drupal. It's going to be dependent on Drupal to render correctly It's going to make sense of usage of Drupal simply override and pre-processing systems And some examples of this that I think we're all going to be familiar with our paragraphs layout builder No, it's blocks terms Display modes, you know Drupal templates and twig all that good stuff. That's going to be a couple approach It's highly dependent on Drupal and you're not going to be able to use your components anywhere else But if you're building one Drupal site and you don't foresee a need to ever use your components somewhere else There's nothing wrong with a coupled approach. I know everybody talks about decoupled and had this et cetera But if you don't have the use case for it Most of them just add complexity So then we go on to decoupled And I I'm not using the term I think and how it's modern and trendy to use it and that we're decoupling from Drupal. It's more of a decoupling your component definitions from being dependent on Drupal So I like to call it independent a little bit. I think decoupled is a loaded term and can mean a lot of things So this is more of when you're doing the storybook first approach Components are created independent of Drupal with minimal or no Drupal isms in the templates So that really means nothing from twig twig none of the special people twig functions A lot of the job script helpers that Drupal provides those shouldn't be used if they're necessary And it doesn't mean that you can't use them It just means that it should be an acknowledgement that you're breaking the decoupling when you are using them, right? Sometimes you just have to and that's that's fine. Sometimes that is the correct solution But the preference should be for not using Drupal isms when you don't have to Templates are intended for using systems other than Drupal, right? So there's a lot of other systems that can render twig So if you're intending to have a symphony application and your application using the same twig components then once again, you're going to want to avoid the Drupal twig functions and Then developers may create components outside of Drupal and then integrate them. This is the storybook to Drupal first approach We've seen some success with this as far as It allowing for any developers to focus on what they're good at right which is HTML templating CSS job script and then not worrying so much about the Drupal side of things And in some examples of this we're gonna be systems like emulsifier outline or particle or wingsuit I think maybe UI patterns falls into here somewhere, but I've enlisted somewhere else I certainly don't have time to try out and fully understand all these systems So if you think one belongs somewhere else, feel free to let me know And I'll happily move it Then we didn't have this components are defined and rendered outside the Drupal Drupal is only really only used as a content store and really This introduces a whole new fun set of problems that I just don't have time to talk about right now So we're going to move on some examples of this are going to be Gatsby, NXJS or drugs Really when you're going on this your component system is kind of the last of your concerns. There's a lot of other problems to solve They're certainly making strides, but it is a very complex approach and then you have your monolithic systems So opinion these are opinion systems They're built on top of a couple of approach and you can see there's a lot of examples of these right so there's Gutenberg from WordPress There's aqueous high studio. There's drop solid rocket ship rain pattern kid CL components, which is a new one and then UI patterns, which I recently learned is actively being contained again so typically these These take a very opinionated approach about how you're using Drupal and they often introduce new paradigms or new approaches for how to solve some Excuse me some of Drupal's shortcomings as far as when you're creating components and how to make it either better developer experience But they're authoring experience better although those are two main ones I Personally tend to shy away from monolithic solutions because I I don't like being bound in by the compromises they make and that that usually comes from a fear of not understanding the compromises when I start using the system I've found that Regardless of what the model is the system is doing. I'm actually going to run into an edge case or a use case that they don't support and at that point trying to customize or work outside the the Envisioned scope or envisioned Approach for a monolithic framework. It's very difficult and very complex and very time-consuming So often it's easier to go back to client say we can't do this and that's never good Well, we can't do this or the student cost you a bunch of money and neither of those are good things to say to a client And now back to our onto common component architectures The first one that we're all familiar with I hope is paragraphs Once again, we're going to be working through this example where we have four Adams header description link in media And then two component specific fields media left media right and background color So starting off we have some simple left-right logic. This really isn't important It's just showing the rough logic that The rough template structure that we're going to be working at The two important things to note or that we have a media variable and a content variable that will be populating With various different approaches So our first approach coupled nestled our first approach is a couple of approaches in nested paragraphs I'm gonna say this once and I'll say it again later. Do not do this I have included this as an example because I having First heard about paragraphs many years ago started using paragraphs didn't approach this way stopped Duke working this way I Still think this is the most logical way to use paragraphs represent components, but it's not the right way and it's not a good way so when I'm talking about this a paragraph what we're really saying is We have our component and then we have an empty reference to another paragraph to represent the atoms, right? It's so an empty reference to a header atom, which is another paragraph That's an empty paragraph and you the reason you don't do this is because you run into revision problems Pretty much every time you click save on the NCM Drupal It creates a new revision and when you're nesting paragraphs You end up clicking save and making 50 new paragraph revisions So your revisions explode causing your database tables to explode causing performance issues and it's just generally problematic. I know paragraphs is trying to work on this and try to solve it But as far as I know it has not been fixed yet. So in this example, we have a template We have the the important part here is the middle where it says that content and says field header field description field button Now this looks nice and simple, right? You think you can read this and you understand what it's doing But what does it really tell us? It tells us nothing It says we're rendering field header field description field button, but tells us nothing about the templates being used It tells us nothing about what they're going to look like and tells nothing about the Values that are actually being used or the data structure that is available So as a Drupal developer, this makes sense and you can probably go dig out what this is doing But as a front-end developer doesn't know Drupal it tells you nothing about what is actually happening. So at that point, yes it As a Drupal developer, we know the easiest way to solve this is to go on to the front-end and look at the Debugging that twigs fits out into the HTML, but that requires that we have a working local Requires that we have our twig debug set correctly It requires that we know where to access this component on the site and if we can't access it that we know how to create it So there's a high barrier to entry with this template for simply trying to work in it and trying to track down I need to make a change to field header. How do I do that? So a couple of This gets into really the complex of it. Like I said, that's the NZ references to another paragraph Don't do it. Just don't this is not a good approach. If you have a site that's doing it You probably want to start looking into purchasing your paragraph revisions so that your database table doesn't explode too quickly and Then the challenge of this approach for field header Is that admirable? There are six possible templates that may be used to render that that field So if you don't have a working local if you don't have a twig debug set correctly, you have to go track down Which one of these six templates is being used and you have to know the patterns to go look for them, right? I pulled this off the documentation But you have to know to go look for that documentation and then know where to find these either in your theme or in your custom models Or wherever it's gonna be some more issues Once again, which simple as does that template include there's absolutely no idea from that just from looking at that twig file What preprocess functions are running once again? There's at a minimum sec at a minimum six to check for for each field and they can be spread across many modules and many themes So there's just a lot to track down if you want to truly understand what's happening with one simple variable And then you need to multiply the number of possible templates and preprocess functions by the number of fields that you have So in this case it's six times four, right? So 24 possible templates 24 possible preprocess functions to check and then Possibly yes, I'd like to assume that people aren't doing preprocessing modules I know people do but hopefully it seems excessive to also multiply by modules And then a benefit of this though is that the processing logic for atoms Can be all grouped together into the paragraph, right? So when you're when you have a preprocessing process for the atom It can work on all the fields and same for the template it can group all the the atom fields together into the same area So there's a benefit to using the cryptic this approach It just doesn't outweigh the implications of performance and eventual database grief that you're going to see Next we're going to look at decouple a decoupled ish approach And this is what I call reused fields So instead of having a paragraph for the header we're going to have three different header fields that are Excuse me grouped together by Field header underscored field name, right? So we have field header text a field header display and a field header element drives under three Adam fields that we need on our side-by-side component and you can see here Instead of just rendering the field header We're instead doing using includes David to include an atom template or an item to a file and we're passing values directly by pulling by using the The field variable to get the value so this is decoupled ish because The template no longer is depending on Drupal to figure out what templates used to render the atom But you're still dependent on the Drupal values to get the actual value that you're passing or the actual value that you explain So you're still very much dependent in the in the template layer up with Drupal knowledge for how to dig out a value from contrary variable and How many of you could try to dig out a URL to a file or to a media item in the toy template? It is not simple and requires quite a bit of Drupal understanding of data structures So decoupled ish is how I'm calling this plus side for this is that the templates are Explosively stated and we've reduced the number of possible templates and preprocessing functions to only the ones that are needed for the entity instead of having six for each field essentially Downside to this is that there's no way to really embed atom forms, right? So any form logic that you have that used to apply to the header forms Needs to be either re-rigging or written at a very high level where it could be impacting all their forms Right, like you need a generic form alter. You're not going to get a form field header alter To do any form modifications for your atoms And then you also lose the ability to bundle your preprocessing logic for the atom fields because once again, they're just individual fields It's not a group of fields that you can act on and then yeah The downside that you have to dig values out of twig, which is just pain ugly Next approach is a fully decoupled approach. So you can see once again here We have included at atoms with header right instead of with the individual values being put into an object We just have a hundred very a question now is where did that header very come from and The answer is it comes from a preprocessed hook, right? So instead of digging out values in the twig template you write a preprocessed hook and you start digging out values using php Which is at least a little bit easier to understand. There's Bit easier to find to debug and find examples for and also you're back and developing to be more familiar you're following this approach then Working the twig approach the downside of course is that you now need a preprocess function for every Every component so what this does on the left? I have an example of the preprocess like this just a Content variable. That's an array for header. Then we're setting text to the MC field value For your for your text element and then on the right. It's the example data structure that would be passed to the twig So you can see it's very clean We have a variable for each one of the each one of the elements in our component and if we go back to the The template we're just including the atom templates individually and passing the the values directly to them because we know that the data structure is going to be correct and we can assume that That variable is going to work with that So that's a fully deep coupled approach because in the template there is no dependency on Drupal, right? You're just passing values and it's passing those values on to other twig templates. Drupal has to do Nothing there is most the twigs is doing everything So benefits for that is clean and easy to read the data is prepared and ready for each template The templates in use are explicitly stated and we once again We reduce the number of possible pre-processing and template functions down to just the ones that I'm to see The downside once again getting a clean data structure is uses a lot of expensive pre-processing Which requires a certain amount of Drupal knowledge a certain amount of php and backhand knowledge Once again, there's no way then but the atom forms are to work on them holistically across the system You have to work targeting them individually or targeting them at a very high general level Then we also sell the downside of pre-processing logic can't be grouped together by atom because they're working at the component level And the self the digout values in twig Actually, that shouldn't be we don't think they got by some twig All right, so that's paragraphs Next we're going to talk about layout builder, which is the other big better to paragraphs First layout builder approach is going to be custom blocks So custom blocks for these kinds of entities, which is what paragraphs are so you can see everything I just said about paragraphs It's gonna be the same The unique thing about layout builder is going to be the inline blocks So you'll look at this template and it looks the same as last one, right? I'll tell you there's no differences and the reason there's no differences is because it was a decoupled template It doesn't matter where we're sourcing our content from For the template we just need to make sure we're passing the values correctly to the template so they can render Yeah, this is this is exactly the same as the previous one the difference is in how we're getting the data structure created So now in the top left instead of having a pre-process hook We have a build hook because we're using inline blocks instead of custom blocks or an inline Or in my in line for using her using an inline block instead of custom blocks or paragraphs. There we go So, yeah, the benefit to an inline block is that it has a block class that has a build function Where you can put all of your logic and you don't need to go put a hook somewhere new theme or in a module, but Other benefit is that you're not necessarily digging through entities anymore You're digging through a flat array of values because inline block store their values As a raise instead of as field objects or field items But once again, we're creating the same data structure we created for the last decoupled template So benefits and line blocks You're defining blocks with the plug-in system So there's one place for the block and it's typically fairly easy to track down Downside to inline blocks. They're built with form API, which is also an upside So form API like I said creates a much nicer data structure to work through Downside to form API is that writing form API forms is a bit of pain and does once again require a lot of people knowledge to Do correctly And then values are easier to access when you're thinking about your form API Another benefit is that the build method provides that one place to do all the pre-processing Is that we're having it spread across multiple different pre-processed hooks So that's the benefits of inline blocks a couple of additional ones These are all going to be the same as The decoupled approach for paragraphs. So templates in the user explicitly stated we've reduced the number possible pre-processing and Template options just the ones for the block There's no there's still no way to embed add-in forms and there's no way to pre-process the logic for a group of add-in fields So after that very long preamble Why are components difficult because I haven't really answered that question I was talking about how to build components and the answer is Because it feels like it's possible to create a component system in Drupal, but it's not So everything we talked about right it sounds like you should be able to build a component system But every single one of those approaches had significant drawbacks or significant dependencies on back and knowledge of Drupal Which a pure front-end developer just isn't going to have so all of your front-end development is dependent on back-end development and That these into the real reason right so the reason it feels like it's possible. It's because you have an illusion of choice There's plenty of options for how to build components in Drupal, but they all depend on the same underlying systems Right. They all come out and see a value. They all depend on field API for API and under API so Fundamentally, there are issues modeling component data structures in those systems and Regardless of what combinations you do you're going to run into an issue is pretty much the conclusion I've come to like there There's not a correct way to build a component system in the current state of those four APIs and that's really why I think building components is difficult because No matter which approach you take there's going to be compromises and they're going to impact you for the lifetime of the site The the little systems just aren't up to the tax and the big the big differentiator. I think right now is the whole concept of needing to embed atoms into molecules and molecules into organisms or Organisms Yeah, not court at all. So, yeah, having to embed Components into other components creates a significant problem in Drupal's current version of field API and Because of that the the complexity of building component in Drupal is not correlated to the complexity of the component is so it's More dependent on how hard is it going to actually be to build in Drupal It's off often would be more difficult to build it in Drupal and you know, just look at the components saying this is the header of text the link in the media developer knock this out in the afternoon and That's because like I said, like I said, it's not possible to effectively model component systems System structures in Drupal. You really need that glue layer that ties Your template to some form of data structure somewhere some form authoring experience and to build that effectively You need back-end developers and you really need some very deep Drupal and p2p knowledge to do it in a way that creates a system that's functional and consistent and System that people really want to use I'm actually to the point where I'm starting to consider like twig twig a code smell because I think it's Acknowledging that Drupal as a system is failing to deliver content or deliver values to a template in a way That's actually useful to the template. I'm not saying never used twig twig But if you're using a lot, it means that Drupal as a system is failing to get you the values you need in the template And because of like I said Your front-end Implantation starts becoming popular that independent on back-end development, which is highly problematic Because you that requires a lot more a lot more communication a lot more understanding of what's being built and Where it has to go through two people instead of one And because that that that glue layer that couples components and forms together is spread right now throughout Drupal Right. It's in templates. It's in three process So it's in whatever else you're using it's really hard to consistently do the same way across Drupal because it's spread out Everywhere and then it also makes it hard to find if you're somebody you coming into a system where you're working on a part of the System you haven't worked on before it makes it difficult to find and understand the code that exists And that's actually interacting with the component which makes it difficult to debug or add a new feature Or to do something the right way according to how this is some husband bill It also makes it very difficult to explicitly document because you end up trying to document essentially the entirety of Drupal Which is a pretty much impossible task for school team And then you're creating a little creating a little style guide outside of Drupal is also very difficult because there's so many These approaches to kind of Drupal doing something to feed into the the rendering layer now the CL Component library the CL library That's being built. It's unique in that way and that I believe is actually using Drupal as a back-end rendering server Instead of just rendering trade directly through your hop script. So that might solve some of that problem But I haven't tried that out yet and then So that that glue layer being difficult to maintain means that I'm sure you're start making mistakes and that Eventually the system is going to become intractable for authors developers and signers authors are going to slowly lose confidence in your system because Invalid content combinations or in value field combinations are going to start to creep in and they're going to get unexpected results Or things you're going to break or things aren't going to look the way they expect them to look Developers are going to get overwhelmed by the number of options and trying to identify the correct way to do something Right if you have three different approaches to solve the same problem, which one is the correct one? and then designers If they're trying to add on a new piece of much time to the site or if they're trying to revamp an existing one If they can't get a grasp of what is there and what is available to them They're just going to create something new and that means as developers or as a product team We have to go create something new instead of reusing the same stuff that we have that could possibly solve the same problem And all that creates a high high barrier to development So during your build your Implantation is dependent on Drupal back-end skills And then after the build when the site is live and you're maintaining it any maintenance or enhancements are dependent on Drupal back-end skills and it's dependent on any on implicit Institution knowledge of the glue layer, which like I said can be very hard to discover And this seems simple enough right what Drupal project doesn't have a back-end developer on it But why should your front-end work be dependent on Drupal back-end developer? Why can't your front-end developer just Get a design start building Why should it have to go through a back-end developer to either create the content architecture do some free processing or do whatever they need to do To get to a point where somebody who only knows HTML, CSS, JavaScript, and Twig can actually do something with a Drupal component So that's really what I mean by a high barrier to development Because you either need somebody with a lot more skills or you need two people with specific skills to get one piece of work done All right, what can we do to make it easier? So I have a whole section here Here's a bunch of core discussions that you can go look into But I was going to say that none of these are really have an attraction and there's no discussion going on in many of them And that changed literally two days ago. So I'm gonna skip over some of my other ideas for the sake of time I still think they're good ideas, but there's something there's a bit of development this week That is worth talking about instead. So Mateo Which goes by this unpronounceable username? Opened up an issue literally two days ago called single directory components Which proposes that we create some a system in Drupal to allow us to find a component in a single directory and that single directory We contain CSS, JavaScript, Twig, and the YAML metadata file So this is a really interesting Approach and I would encourage you to go read this issue It's only been live for the past two and a half days But I believe it's getting about a comment now right now So there's a lot of enthusiasm in the community for both sharing solutions other people built as well as giving input on what they think Should be done and looking a bit more closely This is the goals. I'm not gonna read all of them Because there's a lot but the the general concept is that Drupal should have a way to create a self-contained component that lives in a single directory and Isn't dependent on other parts of Drupal to do to work correctly So that would include even preprocessed functions. There's a An approach here where like each component would have its own PHP 5 So that any of these preprocessing you need to be done that needs to be done on that component could live with that component So it's a really interesting approach. I highly recommend going to read it I will be I'm still formulating my my real response I dropped one in yesterday with some initial thoughts, but I'm definitely aiming to get a real nice long response to that Before that Alright, so next is questions and I'm going to answer the one that I think is coming most which is how am I solving this problem right now The first one is spring planning like I said There's an exam back in developers to really get work done right now So if you acknowledge that then you can start funneling all the Back end parts of your front-end components to back end developers that sprint before Your front-end developers actually need to work on it so that when your front-end developers go to work They have all the values on the page in roughly the right structure Back in both it's not gonna be perfect. They're not going to get HTML structures perfectly, right? But if they get all the values on the page, it's easy enough for a front-end developer to go in and change So sprint planning is a big part of it and just acknowledging that a back-end developer I'm gonna paint with very broad strokes here from my experience if you disagree. I apologize But this has been my experience back end developers And it typically moved through configuration tasks content modeling tasks Relation like field entity reference tasks a lot faster than front-end developers I think it's just because they're more used to working with the the internals of Drupal And they haven't played better grasp of here's what the field formatters do here's what the field types do Here's how they can all be used together to create a solution So I found that it's just a lot more beneficial to say here's a component Here's this data here's the data we need for it and let a back-end developer Kind of figure out what the data model is going to be for that and then get them to put it in a template somewhere for a front-end developer to work on and I think if you are a Fed who says with Kyle that's easy enough to work why can't a Fed just do it then Gradualty since you're not just front-end developer you are a Drupal developer or You're a Drupal developer that specializes in the front-end or your front-end developer that specializes Drupal or your full-stack developer So that's one approach being a developer I've also started to work on my own solution So this doesn't fix all the problems we talked about here, but I've been working on a module called RJSF which decouples forms from Drupal from the Drupal form system So instead of collecting values through Drupal form API, we end up rendering a react form inside of a Drupal form Which means you laugh but it makes a lot of sense Yeah, so It sounds funny, but it means that our form structure is not dependent on form API We don't have to create a fully built-out form API to collect data We just need to create a JSON schema then then a form is rendered using react for that and then it's embedded in Drupal through form API So that essentially decouples the entirety of our component structure and our form definition from Drupal itself and Drupal's just consuming JavaScript based on files It also does work generally better UX I think all these forms are go time material I which I personally just like right right now better than Clara or even Jim and Because this react is generally easier to find the skill set to build out new widgets or to develop new widgets on the right here It's very difficult to see but if you access the tiny roll that's a color quicker. We actually just recently built using our JSF and it supports gradients to support transparencies It's just a very nice color quicker that is difficult find right now that you have control space and traditional Drupal And then yeah, we get access to the entirety of the job script and react ecosystem when we do want to build something new So there's that we've also been doing quite a bit of aqueous I studio It has this ups and downs it's certainly probably one of the best component building experiences I've seen but it has other limitations and drawbacks. So it's not it's not it's not the solutions That's problem, but it is a solution And it's certainly good for lower budget clients if they're already hosting on aqueous All right, that brings us to questions No questions So So The as far as components go and your solution of putting a react format to the Drupal form the The use of Drupal as a back-end is that something that that you Appreciate or is that just is that the problem? How's it right now is a problem for components and this goes back to one of the core assumptions I made at the beginning, which is that components don't store data. They only store content, right? so Drupal is a very good data modeling system when you care about priorities and relations and Data integrity and all that but for components like we don't really care that much for this I don't care that much If a template understands how to render a data structure, that's all that really matters So I don't need the rigidity or the definition that comes with the old API or it's the API I don't I don't need independent revisioning of a component. I just need revisioning with the components parents So yeah, right now there's a gap in being able to store this kind of Flexible data these flexible data structures in Drupal Which is why the RJSF module actually stores a JSON blob in a field in the database So it doesn't break it out into individual values and individual tables for each field value It's just one field that has JSON blob in it and then all the the data validation Enforcement is done before after save before before save or after loading it into a component So yeah, there's a bit of a gap, I think and I think that's that's one of the Things I skipped over here, which is there might be room for a component entity type Which is somewhere between a content entity and a config entity To answer the question. Yeah Do you know Brian, I wanted to ask you about the HACS project It doesn't sound familiar But you had a very similar approach and then a bad way to approach it was to go full-on or out-of-companies Yeah, and that's all it was I think it is certainly a challenge we're decoupled in on this project. All right I think if we have one more easy question If not we can call it here