 So for everybody coming in late it's it's so much easier to tell if you're in the right room because when I came in here this slide wasn't up So I couldn't tell like I'm in the right spot Okay, so Today we're gonna talk and it's gonna be a discussion not me talking About triple nine components library the next theme system Those of you don't know me. I'm John Albin Wilkins. I'm a currently a senior front-end developer previous next and I've been doing Drupal since Drupal 4.6. I think I mean I 4.5 was like the latest release when I first looked at it, but it actually start using it until 4.6 was out so I've been doing this for quite a while and I I gave a presentation in Drupal con San Francisco right before Drupal 7 was released and and showed the Simplified view of the D7 theme system here If it was fairly complicated and Somebody asked a giant room full was it was it Steve was it you who said who do how many people here? Understand the yeah this diagram and it was basically still just me No, wait, were you there? Yeah, so if you've been in the number two people right with their hands up We're not going to go over that really this is a super super simplified version of the just the theme layer of Drupal 7 and And and yeah, this still applies to Drupal 8 as well Basically your your data comes up from the database and all the other places And then the modules are what's in charge of providing your markup JavaScript CSS they all come from the modules originally and then the themes sort of override those bits as it passes through the system to end up and You know the end users browser And this this was certainly a fine architecture when we came up with it but nowadays There's really been a sort of revolution in the front end about We've sort of finally got our act together like hey, we can do architecture, right? so This is much closer to what a modern front end Architecture looks like right so the heart of it is the component library so each of your little chunks of design are Encapsulated with a a chunk of HTML a chunk of CSS You know optional JavaScript as well, right so The that thing which is called a component, you know has everything that you need in order to style and display This piece of the site, right? so your component library becomes a Collection of all these design elements that are then put together right and You know oftentimes you'll have various preprocessors so you can convert sass into CSS You know coffee script into JavaScript that sort of things but those those are all within your component library and Because you have the system you sort of need to have it all documented So you'll often have a style guide that's automatically generated from the component library that lives next to your component library Like hey, this is what's what's going on Inside this component library and then your application which is Drupal in this case right is Pulling those resources from the component library. It's got the data and it goes okay. I know that I want to have this thing Styled in some way right so I'm going to grab a component from the from the library and say My data goes in here and then send it off to the rest of the system, right? So This of course is a lot different than what we currently have But the good news is that Drupal 8 has all the pieces we need. They are just in the wrong order and This is the last slide really so if you Look at this and start thinking about Okay, what do we have in Drupal 8? How can we rearrange these pieces so that they make sense and can fit into this model? The theme registry you know where we have this collection of template files right now That's effectively the component library. It's just not It lives the route all these different modules and we need to take the theme registry and convert it into this is a component library right And this is where all of our temp our individual components live and their their templates and their JS And their CSS right and if you look at an individual component you realize that since it's a bundle of CSS and JavaScript and HTML it it maps really closely to what's considered a library in Drupal 7 and Drupal 8 So again, like they're in the wrong order. They're also named wrong, right? So We've got good things. We just need to like put them Into this order so that it makes sense to people coming from others other systems, right? And this is gonna help us as well, right because it turns out that back-end developers There's two problems, right? So because they're in charge of providing the markup in the HTML One they're not that good at it. They're not good at writing HTML And two they're not really that interested in writing it. Well, I We've been doing this concept of development at previous next and One of the developers there Cameron He he texted me and he's like man John. I love the style guide stuff Because you know, he's looking at the style guide to figure out how to get his His chunk of his data to look like the things in the style guide and all he has to do is go and look at the style guide and Grab out some some classes and stick it into his markup and poof, right? Like it you see so he said I love the style guy stuff because I can make things pretty Right, so if we give Module developers a style guide of the Drupal system They're gonna be so happy. They're like, oh, man. Okay I just have to like use that component and it's gonna look like this like they just sort of like put all these design Pieces together and it looks pretty right instead of like like ass, which is what it usually looks like, right? So this is my my concept of of what Drupal 9 should look like and Effectively we have this component library and the module developer says I've got this data I want to hook it up with this particular component and send it on the way to the system. So I Have a vague idea of what themes would be they would basically just be Ways that you would like rewire those connections And in that case like so you would get this this chunk of data with the like I want to be put into this component Along with some context, right so that you know What's going on and then based on that context you can rewire it to be a different component library And it would be a really simple switch Usually you would just like oh instead of that component uses other component, right? now Drupal is gonna come with a a much smaller set of components that currently comes with Theme hooks because they're just kind of crazy on the theme hook outside right now but it will be possible for Modules to you know register a new component to add to the library right so like if they go through the entire style guy And like I can't find anything that I need they can you know go and add something right so The date module is not in core is it in T8 yes Right, but it's not like the pop-up widget of the date picker But sure But yeah, so that's a pretty specialized component is what I was trying to say so like Maybe that's part of cores component library Maybe it maybe it's something that the date module registers into the component library, right? and Like that's it. That's the big picture and I'm but I want to like Have everybody discuss sort of the nitty gritty details of like how we how we could fit all these pieces together Because I just didn't want to overthink it before I got to meet the really smart people who can collectively overthink it Yes So What do people think? The microphone please. Yes. Okay. Are there small things we can already do in Drupal 8 that would help Transition is it not all I think it is on Okay, really close. Okay, so are there things we can still do in Drupal 8 as in Things that are named slightly awkwardly that would a rename would make it easier to transition to this world like for example libraries of the ammo That kind of makes sense. It's an asset library But we didn't have him better if it was called components or assets or stuff like that Are there such small things that would transition make the transition easier? Well, I mean I Don't think I don't think there were things we can do in In Drupal 8 and 8.1 or 8.2 that we could like I Don't think it's wise to try to make those changes during any part of the eighth recycle We're already we were you know Morton and I and and all the themeers are trying to simplify all the markup But just converting it all into twig was so much work already We didn't we haven't been able to like shrink that code base of all the theme hooks, right? so Simplifying that the theme hooks is going to be one of the first steps So so renaming some other bits is just going to cause inconsistency. I mean it's already inconsistent So it's fine if we just keep them named the same thing during 8.x, right? But as we get to 9.x and we certainly do like have an actual like plan of like okay Libraries get renamed the components or you know things like that Have a list of things that that need to be renamed so that they they match the front-end architecture Hey, John, I think Steve. I think yes, there are things that can be done in the 8th cycle I think the the simplest Version that you're talking about is Moving files we already have so we already have template files. We already have CSS files that I hope are broken up such that they line up with the template file, but maybe not But I think it's not they should they were trying to get them closer there and we can continue to join that during 8 You're right, right. So I think it wouldn't be That radical to say Instead of putting templates and CSS and JavaScript into separate directories per file type We're going to move them into separate directories per component I think that would not be that radical of a change right now in hook theme You don't declare the CSS and JavaScript that's expected that has to get added on to the render array at runtime Which is different from? Render elements, which you can say this render element always needs this CSS and always needs this JavaScript We could add that concept to hook theme. I think without breaking backwards compatibility I think that's a change that could happen in the eight cycle take out the places where Libraries are added at runtime and move them into hook theme that I think wouldn't be that big of a change and it wouldn't Break backwards compatibility wouldn't stop people from adding libraries at runtime Just core adds them in hook theme to make it a little more easier to understand Long-term I do think we would we would need to do something as that break backwards Compatibility because I think this idea is most beneficial when each component can be named independent of Its data structures right now node is the data structure node is the name of There will be no node component. Yes Yes Yeah In the previous Poor conversation I was I was giving the presentation what panels can teach us about web components and right now panels can do that It can have the layout plug-in be named something completely separate from What's this the source data object and in panels layout plug-ins you do this kind of declaration of you say This panel's layout always needs the CSS. I don't know if it has a place for JavaScript But you know one more property to declare. Yeah, I mean just an aside So layouts are also just components. There is you know a specialized kind of component But they're just like some rapidives And you know placeholders for other data Like that's that they're simple Exactly. Yeah, yeah the out of the box panels use cases like Kind of global level layouts, but in implementation. I use them all the way down to new modes I've probably talked enough Steve for for the thing you mentioned the ability to add to attach assets or attach asset libraries in hook theme Something like that actually is already in core so not for hook theme But actually within the twig template itself so in within a twig template you can now Say attach underscore library so the attached library function there and then you can just say okay attach this library for this twig template But if it's then overridden that twig template you have the choice to not add that asset library or add another one or do whatever So I like does that fully answer that need I have the sense that it does because it even then allows you to not have to deal with PHP at all because it's then completely in twig So just so you know and hopefully that is sufficient. I'm not sure I'll say I I don't know I don't know how much functionality we want to put into The twig template. I think when we introduced twig the idea was let's make these templates as simple as possible let's make it so that they're not responsible for much and As we found out all the things twig can do we're putting more and more responsibility Back into those twig files because we're learning all the things they can do should they I don't know What what is the thing that defines the component is the thing that defines the component the twig file and the twig file says What it's CSS is or is the thing that defines the component a Class or an entry in a YAML file and there it says this is my template. This is my CSS file So so I I would like to Point out like there's this technology this future html technology called web components Which is basically templating system inside the html language itself Steve, I think you've heard of those before right? Yeah Right. Yeah, which Steve just talked about. I mean like in a session like a whole session about it so if you didn't see it go watch the video, right and Like I think we should try to you know Look to the things that are obviously going to be like some sort of consensus And I don't know how web components work enough. I haven't looked at the spec details enough to say How do they bundle up their CSS and their JavaScript into a web component and we should try to follow that model There are there are a couple ways but one of the ways is to say that the web component is This dot html file and then from that dot html file You can either the CSS or JavaScript is inlined or there are other ways of referencing so I Think one of the goals here is making sure that our our concepts line up with the concepts that are going to be used in Modern front-end tools like web components so that even if the specific technology changes It's it's harder to reprogram us than it is to reprogram Drupal the concepts we Tell ourselves are much more deeply ingrained than the ones we code into Drupal Change gears slightly here Going component library sounds great components yay But there's still the problem of what the pipeline is for rendering those the reason we have the giant cloud of Arrows that go everywhere to define our theme system is because we have not made up our mind whose job it is to pick which component is gets used where and if a component has any configuration or can vary whose job is it to to decide that We have not said no to any given workflow, which means that we say well you suck to every workflow So if you want to go this route, I'll ask you what workflows and what functionality are we willing to just say no To and not support in this approach EG are we willing to say semantic views go away? You just don't work because the template should control that the the component that self should come should control that how much configuration do we want to allow in a One of these components and Morton's coming up because he's gonna disagree with me You know what What piece of our for overlapping theming concepts are we going to just jettison to make this possible? Because we can't not jettison some of them. Which ones do you want to jettison? I have a feeling that maybe Morton has an answer to this particular question So I'll let him just go with that So we had this discussion in Munich That's three years ago. One of the question was always like how do we want to control our markup and And and the we've asked this question out a lot of times we did the survey last year We have a very small group in the front end world who want to have Configurational fields and have to go in through a UI and click and do stuff and say this should be an H1 And at this class and do this class the overall thing I've always been like put it into template files And it's like 80 90% who wants that so I think we can I would put my head on the what's it called? Chopin block. Yes. That was the name for it and say that well The the configuration put it into the template so we know where it's at. That's where front end usually work We don't want to be able to like do this stuff two different places Have it in the templates. That's what we're already doing now with how you control all your classes So a module like the semantic views is kind of not needed because semantic views got built Because it was across the fuck to change these things have been easy to do that directly in the template the module Never been built. It was kind of tools where I was trying to fix all the symptoms If that helped up to figure out which things we're gonna chop off I'm perfectly okay with that as long as we decide we're going to make a decision on some of these if the decision Is that direction? I'm cool with that. Yeah, I would also like to see a A Simplified flow. I mean this is this is women's excellent Drupal a to request handling and rendering flow and it gets Way more detailed than I ever Imagine was even possible early And so I would definitely go check out his session if you want to check out the the date pipeline And he's popping up here to say something but I Would be fine if we could simplify the number of places where you could do things I Would say that you know The the module says okay, here's my default You know data or here's my data, and here's the default component I want to use it like and then you know Maybe other modules can come in and modify the data I guess because I still need to do that and then like the next step would be then the themes get to decide whether They want to rewire it and like I don't see a whole lot of other things We could simplify all those different ways that you can change things Pre-process and you know all the things that we had Just really simple clear steps of these are the you know couple places that we do and and also One of the things that I just hate about render arrays Is that it's it's self modifying code right now? so like depending on the things that you stick in the render array it will change the way it gets rendered and It has all these different callbacks and modify each other That just drives me crazy it because depending on when you access that render ray There are different things in the array because bits of it have self-modified it to add more children and more prefixes and the libraries can If that can go away, I would be so happy Yes, unfortunately the render rendering flow the diagram you have right there is Pretty much in completely independent of what we're talking about here. This is more high-level Sure terminating what should be rendered and so but yeah, it's definitely really it's where is it the the bit? We're talking about I guess is just down here. Yeah, so basically HTML renderer. Yeah. Yeah, and even that is just It's mostly independent of what we're talking about here. But yes, that is the most relevant part of it but I wanted to talk or Reply bits to what Larry and Morton were saying. I totally agree that it should be much simpler and actually That strange interaction between render arrays which are supposed to be the single source of truth and then Themes as in tweak templates overriding things like that those things always Like there's always friction and there's always confusion and problems And there's lots of bugs because of that that we had to find had to do complex things for to actually work around So yes, I would also love it that everything was just in a template and all the configuration would be going away But I think there are actually different levels of configurability there So for example, you were saying that I did the title field Maybe you should have an h1 or an h2 or something else. Yes, that should be in the templates That shouldn't be configurable in the UI But then there are other levels such as if you have a node and that know it as many fields What is the order that the fields are rendered in like for side builders? You kind of want that to be configurable in the UI, but then that kind of conflicts what you're saying But not entirely it would be much easier if we could get rid of that And then everything would be the single source in the single source of truth in the template But can we actually do that because I think part of the answer part of the question that we have to ask here is How much power do we want to give to the side builder because that kind of conflicts with the front-end person? Microphone Do people understand what I'm saying contemplate what that is and how evil contemplate was So contemplate is basically able to edit your templates. They're really in the browser Which can be a really really awesome thing Because we feel dangerous in with trick we don't we can't drop our own database. We can't do really dumb stuff So what if we said well You want to reorganize your stuff? We make it easy for you as a site builder to do that stuff instead inside of this file so you have So you could go that way instead So you actually would just edit your template files and put your data that way And I know that maybe it's gonna destroy some of the site building idea if you just No mindless can click and move your stuff around But how much how many like I'm gonna feel on the field about how many times you're actually moving that stuff around I mean, seriously so Way back in jupy con Denver perhaps back in the like yay. We can do anything in triple eight days We had a conversation where where we talked about you know if we get twig in Twig I mean those are trig templates, but they in the back and they get they get compiled to like PHP objects Which means that you could theoretically You know in introspect them I'm not a backend developer you can introspect them and then you would be able to you know to if you could look at it in the right way you could have the the content administrators forms like lockout different things saying like well this template as Prevented you from doing this feature. I'm gonna gray it out right sort of thing You're talking about a conversation in the bar at Drupal con Munich Okay, sure. I remember discussing that with Sam Boyer. Oh, yes, I found your water. I think you came by Yes and it It basically came down to the idea of I was misremembering how tall the beard Replacing the like the panels UI and stuff like that become GUIs for editing twig files that have extra annotations in them of some kind and then You know you instead of saving a config object you save a twig template and that twig templates Has extra comments in it or whatever so we can then you know modify that from the UI But you can also just grab that twig template and Morton can have his way with it Actually doing I think there's a den those are bad can be you know have a go one of the dreams that came up We begin to discuss these ways of working was the idea of building What's it called chrome extension? So, you know a front-end that works anyways by sitting and viewing souls so much So what if you can actually have a chrome extension? You could click directly and you can be to modify stuff and send that back to To the site because we're using this contemplate idea. So we kind of we kind of kill actually the site builder Which I'm fine with But that's a that's that would be a concept that we then need to figure out all go both ways for say well if this is This is an element that the theme is over Freighten over how do we then modify that we need and by the way we need that module at some point. I'm not going to write it Yeah, I mean in a super fast because I just say Morton was just up here and I can see Kevin get in line here and and I I Would like to point out that the style guide here even though we haven't talked about it at all It's going to be an essential part of of triple nine Because it's it's the guide that allows the developers to pick the component they want right you just look through the style guide Oh, that's the thing I need for my data, right? and of course, it's going to make all the designers happy because They'll be able to Implement their you know their design system as a component library, right so themes can have their own Their own component library, I'm not sure exactly how that would work, but that's why we're having this conversation right so That's gonna be a really critical part. It's not just like oh, you can also do this It's going to be in core as well with the component library. I Just wanted to I'm not going to make a new point or something I just wanted to stress that we should not forget about the side builder aspect Because maybe all of us here are front-end people and then it's quite possible that we are fine with just getting rid of that whole experience Which could be an option, but like we have to actually consider which way we want to go there and just not forget about that aspect That's all. Yeah, I I think that like I said this this rewiring bit where you like change we decide I'm going to change what component for Is being used for this particular piece of data I think there's that a contrived module could come in and be like, okay I'm gonna make it gooey for this right and Yeah, we wouldn't necessarily need it as long as that would be possible. We wouldn't necessarily need to have that in core I mean, maybe we would but It seems like it could be done So the conversation When I got up here, of course have changed quite a bit So let's see if I can figure out what I was gonna say that might fit back into a row right now Something interesting we're doing on redhat.com right now is we do have a component library And what we're looking to do is actually take this component library pretty much completely outside of Drupal Into a place where Drupal can access it But it also our style guide can access it or WordPress or a Java app or something can access it So it's actually like an external rendering engine that is doing a lot of these same kind of things So we have a bunch of templates which reason swig which is practically twig on node Where we're able to send data at it as just a big JSON format and we turn market back to it And the nice thing with data is you can easily edit the data So the whole site building portion of it is like what order do the components go in just depends on the order of the components inside of That data structure so, you know any of that editing any of the The site builder theme or kind of thing would be editing the data that gets eventually passed to the template engine So then once it gets to the templates all the logic gets done there the markup is then returned back to Drupal And whether that's done inside of Drupal in that kind of method or if there's this external thing The process is still kind of similar. So everything is data Everything is just basically configuration of all these of all these templates before it gets rendered and then sent back Sent back to the system. So that's the way we're approaching it One of the things that we're doing to help that out is attaching schemas to every template So we have a JSON schema that describes what all the template fields are The the valid values for each one of them the required fields and those types of things So any time that Drupal ingests a component it can say hey, this is all the stuff That's required for this if I need to toss it into a node It can automatically out of populate that node with all the fields that are required for it and all the validation for it So there's a really good conversation between this this component, which is extremely Non-drupally, but can be adjusted in and can be accessed through the API Whether that's the Drupal or what style guide or anything else you start throwing at it So I know really where that's gonna go if that's gonna mesh with where Drupal's going or if it's just an interesting way to look at the data I think it absolutely would be Way Drupal is going and I think that it would you know We should make sure that when we're you know doing the actual coding for this stuff that we make it possible So that you know our component library is has sort of a light integration layer So that you could write a you know a new one so that you could just swap it out with like Let's say that web components the technology is not ready when triple nine comes out So like when it is ready, then you could write a wrapper that swap it out Or you could write one that swapped in angular component library, right? And it just converts the PHP data into JSON and then sends it on to this at rest the system Yeah, that's what I would like to see yeah So you have that really clean separation of Drupal is plain data together It's basically creating the structure of what's on the page, but the whole rendering portion of it is a black box and You can change anything that happens in the black box to the configuration and you can set up what those configuration options are A nice thing for this is then you're able to use the same system regardless It's an API so Drupal can access it any site can access that your iOS app can access it It's it's not something that's locked into the Drupal isms of what we're using and you know what that now that I You know now that you brought that up I think that might be a good way to sort of enforce the simplification of how our rendering goes because Once you get to that integration level you basically like okay Drupal land objects You were no longer allowed to touch this because it's going into You know the rendering layer or whatever right so you've configured it all and set up and you're pointing it at the right Components, but now you have to stop Then of course you get markup back I mean so this isn't purely headless the markup still comes back to Drupal You know they can still cache it they can still do what you need with that markup, but yeah There's a pure separation between those two We're we're kind of doing this at the moment when we still have templates inside of Drupal But all the devs are doing is just pulling the content down and basically plugging into this internal API and it returns the markup And I mean as you said the devs love it because they don't want to fill with markup They don't want to worry about what that return is that's the point of the developer And on top of that we have the idea of pushing out releases of our back end So if our back ends are sorry our front end so if the theming engine is completely separate we can actually push out versions Version version tagged versions of this And so we're currently working on one version while the developers are implementing another Well another one is live and we continue push versions out like that So if you have multiple sites that are working off the same theming engine one might be on 1.2 No one might be a little bit older on like 1.1, and they can update to this new versions whenever they want to it's an API It's it's semantically version of all those types of things I really want to see Drupal get to that point and I think one of the key pieces you described in your architecture is that these components described to some degree what they're expecting and I think Drupal core can get a lot better at that a lot of our Theme hooks say I expect element and that's it That's all that's all they tell the rest of Drupal because they're counting on this other pre-process layer to just figure it out for him Going forward we need to get much more explicit about What does a theme hook expect because then we have the opportunity to swap it out if If all the theme hook says is I expect an element and all we can do is throw our hands up in the air and say well The pre-process is going to figure it out, but we can't Expect a web component to be able to reproduce everything that's done in the pre-process Now if we knew explicitly all that theme item list expects as a title the type of UL or or OL and then a list of items Any we could all rewrite the item list in PHP we could rewrite it in twig We could write it in pure JavaScript that that is a theme function that we at least have an opportunity to push out to a web Component right now pushing off the node to a web component would be extremely difficult because so much Happens in the pre-process layer that would be difficult to impossible to replicate In a web component So we need we need our components to describe what they expect and what they don't expect and that also gives us an Opportunity to avoid that breaking the UI problem We're talking about that as if it's a bad thing that we don't want to introduce as if that's not happening all the time now How how many node tpls have you overridden where you take that content variable and then you print exactly the field you want And exactly the place you want by doing so you're breaking the UI That field is not going to drag and drop anymore. So yes, it's a problem, but it's not a new problem to avoid It's a problem that's been around As long as I've been developing Drupal. I've been breaking the UI. I've been breaking the UI Since like cck2 or something exactly exactly so so yes, it's a problem, but it's not a new problem to avoid It's a current problem that we can make incrementally better I think some people may have answered this question a little bit already and you know, I won't pretend that I totally understand, you know, you know everything that's being said in terms of you know You know the underlying process is here But the conversation that I had with Sam Boyer to bring Sam Boyer back into into the into the picture about While it was in Prague at about two in the morning Was was exactly about this user problem that I that I sort of opposed to him Which was you know, okay in the future, right? imagine if Somebody could go to the front end of their of their site and begin to As a as a as a sort of a site builder slash themeer Do things to their site directly from the page that they're looking at to change those things and essentially You know Sam gave me a lengthy explanation But what it kind of boiled down to was that you know this introspection thing that to allow people to change things from the front end in Drupal was like following the path of a Ball back through the pinball machine to where it started to be able to figure out You know where that functionality or where that piece actually originated from and That you know, it's not like that Drupal's render array is not an MVC It's not something that has a contract where you can clearly trace something back and say Oh, I can change this on the front end now because I can say oh that is connected to this is connected to that I think some of the things that people have been saying, you know before me suggests to me that maybe that this is becoming more possible You know that we are you know that we are that we are getting to a point where you could in fact You know and Morton sort of I think creeps towards this with like I want to be able to go right through The UI have a window through the UI into the into the twig template And then be able to change that and be able to see how that affects things But I think that's kind of a it's kind of a halfway there measure Ultimately, we want to give people, you know a fluidity of being able to Change their site and and and and do things With the immediate and direct feedback of What they're doing on the front end of their site and to do that you have to have this thing that that Sam talked about this Introspection this contract where I can describe where I know where everything is that is on the page is described in some way that There's some kind of a manifest there That says this came from here this came from there that came from there So if you want to rearrange this and redesign this the pathways back to where the the things originated is all there And I don't know how much of that is there now in Drupal 8, but but I think that ultimately for me right When I think of users and designers and developers and their experiences and Themers right what we want to get to is a place where people can do that, right? We want to get to a place where people can Have a more direct and immediate control over the things that they actually see in front of them and the ability to Manipulate those things to get the end result. They want And There's an example I can think of an in Drupal right now. That's similar to that. It's a horrible experience, but it It's panels when you switch layouts, right? So when you switch layouts, it tells you okay Effectively I'm you're gonna move these These chunks of data which are regions, you know from this one layout into this other layout How do you want to map to to this new new layout which has different arrangements of stuff? So Yeah, I I agree in that having the ability to do those mappings in the front end Force and users is going to be really useful. I'm not sure I want to make sure that's absolutely a hundred percent possible and whether it gets into core or not I think we still It's it's tricky because like sometimes you architect things you're like Oh, it'll be possible and then you find out when you go to do it that is not possible, right because of whatever bug or Thing that you've done So there's a little bit of feedback loop whereas if you say we have to have this feature in then at least you're sort of checking yourself as you build the architecture so I think I think that I think the The central point is you know is it's great to have components and It's great to have style guides and it's great to have and those things map to design systems You know and that's and that's a very sort of and it's a very sort of bottom-up way of thinking about about design and Structure and I'm when I say design. I mean design, you know with a with a big D You know that the design of all things design is how you know job said design is how it works, right? It's it's the it's the architecture the way that the way that this thing is structured and and and the components and everything like that is That that's the bottom up But we need to sort of build from the bottom up with this view of An ideal future state of top-down, you know where where my front end has enough stroke has enough Knowledge of itself, right and where it all came from and how it was all constructed So that if I wanted to make a contrib solution where a user could literally start dragging dropping and moving stuff around and Say okay now save that as my new theme that they could do that, you know, I mean That that that's a tall order, you know, but but I think if we if we just at this point don't think about That functionality, but just think about Are we doing that? Are we are we are we are we creating this sort of like? you know Description of the page this this you know this this thing that sort of describes the entire render page rendered page and Where it all came from so that if we want to if we want to go back in from the front end and do things to it We can do that Yeah, I agree. I yeah, it doesn't make sense, right? Yeah, I mean Yeah that's why I tried to start with like the a High-level idea and I get into the nitty-gritty, but you need to make sure that we're Exactly what Kevin just said always making sure that we're keeping that as a mind because otherwise we can go astray by Getting into the nitty-gritty of our technology Kevin thank you. There's an excellent segue to the point they want to make In order to do that we've touched on this in a few places There's two very important things we need to Leverage strong typing and coarseness We're talking about you know it was it was from red hat I was talking about you know a component or a template or whatever that can describe what it is it needs That's called strong typing That's exactly the point of strong typing is clearly defined This is the data type I need in this place and that can be checked at the language level That's that's checked at the language level It can also be introspected by the code and then we can build you eyes off of that metadata That's baked into the language so step one is using very strong typing if you have a variable. It doesn't have a type you are Robbing yourself of the ability to verify and automate your code PHP traditionally has been a loosely typed language. So we can't do that. It is getting stronger all the time By the time we're in Drupal 9 will be in PHP 7 which can do if strong typing even on primitive We should be doing that And by strong typing I do not mean to type data API in in Drupal 7 please they're in Drupal 8 Please do not confuse that with actual typing It's no The other is coarseness This is not a new conversation if you go back about three years JC and louisey had an excellent blog post on Design components in Drupal and one of the points she made is we need to be a lot coarser with what these objects are Which means we embrace this fully theme item list ceases to exist because that is too fine-grained a Thing to be thinking about Okay, so he's gonna disagree with me any moment now No, TPA will go away Because it's way too specific. It can be a lot more generic But the like part of the problem that Kevin's talking about you know How do I know where this is coming from that and Sam was talking about the the following the ball back? it's because Our theme system and render system are too deep You just get too fine-grained in where we're capturing things which means it's intractable to Work your way back through the system because there's too many layers if we want to do this properly We need to have fewer layers at a coarser level and those need to be strongly typed in terms of What they need down to if it's you know a note of a certain type if it's a Structure like this like a view model object of some kinds that needs to be strongly typed Because that information lets us in that information that reduced Scope reduced number of variables from a coarser grain Breakdown for our components lets us it build that kind of fancy introspective UI It brings that it gives us the metadata we need and gives it to us at a Size of the chunk size that we can manage and if we could actually build a reasonable UI on top of if someone is so inclined Currently, you know, you could not build a UI for render API that could do that You need something that's much more strongly typed and much more coarsely grained to be able to pull it off There's plenty of other benefits besides the UI to stronger typing in coarser grained Display which we can get into another time, but that is the direction we need to be moving Larry it sounds like you're quoting my presentation where I had the the slide that looked at traditional Drupal core theming where Each theme hook is of equal importance and you have a comment inside of a comment wrapper inside a note inside the page Fields inside the note inside the page all of equal importance. I think this is the problem. You're talking about And that's true even within a field you're probably calling multiple theme hooks inside of one field. It's Overwhelming one of the reasons I like panels is because I can draw those course boxes and say I care about the overall page layout I care about each view mode I Care about individual blocks and within that I care differently I care very strongly about calling each view mode its own design component and everyone corresponds to a layout plugin and my directory of layout plugins is basically my component library Those layouts in Drupal 7 in Drupal 6 Can allow you to think this way. It's painful. It requires a lot of experience with panels module But it can be done Yeah, otherwise you're stuck tracing the pinball the the slide I've got is Plinko from the price is right where you look where did the Pinko slider Plinko slider and and try and follow its path back up and it's so frustrating The first site I make in Drupal 8 if panels isn't ready the layer that I'm going to work at is hook template suggestion I think that's what it's called where We we now have a centralized place where we can more cleanly say something we could say previously in pre-process functions core I know you're asking for Theme node or I know you're asking to theme An article teaser in this one hook. I'm going to replace that with my design component Illustrated list item. I think that's a workable starting point to say a Given page is going to call a hundred theme hooks, but these ten are the ones we care about most and we can And we can replace No hyphen hyphen article dot tpl with either illustrated list item dot twig sorry dot twig or Anything else and now Larry and women are going to tell me why that's a bad idea Actually, I'm just going to suggest Steve at some point you now should do back-to-back presentations that consist of nothing But that's quoting each other because we seem to do that anyway so I agree that The ability to say which things in a certain templates What kind of data that can be that that is super important and that that is the only way we can Sort of decouple because this is also about the coupling right you get data and you have templates And you have to figure out a way of how to make them interconnect and where to get data from Courseness is also very interesting. I think but then new questions arise if you combine those two Because if you're going to be coarse Are you going to be coarse in a way that is describing what it's going to look like or what it is semantically? But even this regarding that aspect, let's assume that either of the two makes most sense is clearly better than the other Then we still have the the problem that you need to be able to specify Okay, this course template accepts these kinds of things these this kind of data But then your course thing is actually starting to be tied quite closely with things that aren't course that are very specific things And I think that is going to be very interesting and challenging because then you have course templates that are tied first maybe to relatively Course things very broad types. So for example, just hey accept a string in this particular bit But then maybe another part is saying I need is no type which is a special type of string and so Start imagining that you have an entire style guide with many components And there is going to be nesting within those and then within those nestings Within each of those templates, which are already nested You are going to specify this as a kind of data I want and then there is another team that it may be going to override a Default component from the from the base team and that maybe is going to then have more specific or maybe even less specific requirements in what kinds of data it accepts and I think We shouldn't forget about that either because hook theme may be ugly. I agree but it's lack of Typing also means that that's another problem. You don't have it causes other problems But let's not forget that Specifying that typing information is not without complexity and trickiness and how to combine things either And I'm hopeful that we can find a good way, but it is not going to be easy It very much reminds me of semantic web stuff where we were supposedly defining ontologies Very broad things and within that more specific things And that is taken off has taken off in some regards, but not on others And this feels very closely related to that because what we're basically building then is a relatively complex Taxonomy of things and how they all fit together and that's what we need in order to connect all the dots But it's not going to be easy. I think hopefully somebody has good solutions for that, but it's going to be interesting Yeah, I I Want to look at like the web component spec and see like because I have a feeling that all those little bits and They are they more complex and like this is a string I need these five strings to put into my template like I think that's still evolving In my research for the web component presentation I did I worked at Polymer's documentation a lot and I couldn't always tell which Thing was a polymer thing and which thing was Web components there. There definitely are emerging standards for how to do web components say What they expect? They can expose public properties saying I expect a title. I expect a date things like that Is it good enough I don't know yet But it certainly reminds me of the dependency injection container the idea that on the server side we can say This this class needs this service and all it knows about the service is that the service Matches the interface. It's counting on Being able to call these methods How it does that? Doesn't necessarily matter. I think we need a similar concept on the front end the ability to say We're rendering a node and we know to do that we need something Compatible with this interface either an actual interface or at least the concept of of an interface And We'll see how that gets implemented specifically in web web components And if we can line up with those concepts so that we're positioned well for web components But not marrying our self-to-web components before they are ready Yeah, yeah, I agree Finally stopped lining up. There are like two minutes left in the session So I think now's a good time to say thank you for coming because otherwise this session would have totally sucked