 Yes, we got working slides. Should we try it on full screen? It's not video, but is it related to PowerPoint like? So please try it on. OK. We are online again, hopefully for a little bit longer this time. These are PDFs now, so let's try to do what we can. In Drupal, everyone is writing modules, but one great thing of Drupal is you don't need to write modules or code. So this session is dedicated to the professional site builders and hobbyists, because one of the best things that made Drupal great in the beginning is you didn't know how to code, you didn't need to have formal training, and you could still build yourself a site. And this is really, really powerful. So all the modules I showed today hopefully are empowering these site builders again some more to make better use of it, because I feel that's a little bit of a part of Drupal that we as a community or a score, especially, have a little bit neglected. And while in other parts, we obviously also have improved it a lot, but there's always more that you can do. So today's session is about components, which is a topic pretty dear to my heart, and I think it's a keystone for building sites without code. We originally started with a vision for components in Amsterdam 2019, and we find it online in 2021. The idea is to never think about theming in the traditional way again, but instead use the modern concept of components. So Drupal 6 already was pretty close to components of how they are today used in React and other things like that because it was pretty pure, but we kind of lost that over time. So what is a component? A good component example is a card. You have image, text, and call to action link. Components have one property. They are independent, and that is really important. That means they are completely self-contained. All of the styling and interactivity is intrinsic to the component. Nothing comes from the outside. So the goal is that a component, regardless of what you do, is always looking the same way. So that's a really, really important property, and it's one of the reasons why components are so great. Because of these non-dependence, because of them being confined to its ways, you don't have to deal with so many side effects. So that's a great part for components. In practical terms, this means a component is composed usually by HTML, some CSS, and JavaScript. OK? So like very normally, you have the HTML, the CSS, and the JavaScript. And then a component has some kind of input. So you have the properties, how a component is styled, what a component is displaying. And then in the end, the children of Y, not really, but some complex inner content. So to give an example, a very, very simple component is here. MyCard, card equals card. And a more complex example that you can see is we have a MyCard. We give it a property of a red color. We are putting a card on it. And inside this component, we are putting another component, which is a CTA component. I'm just going to continue. OK, there you go. You can see. So with a simple component, you could still have the MyCard component get out to a CTA component. But this is just a little bit of a different way of doing things. One thing is slotting it in. And the other part is essentially having the component self-decide of what's happening. How to reach those independence, there are different ways. One of them is the BAM notation. That means you are defining very defined classes that are only applying to this component. In the front end world, we also have styled components, scoped components, and several others, where you're essentially using inline CSS or putting CSS directly to your component. And the JavaScript framework is doing some magic to applying that. But for a pure, more droopal, back end way, we have this availability of defining classes, like class, card, and card title. And we have the ability to define TAVEN CSS parts. TAVEN CSS, if you haven't heard, is very dear to me. I really love it. And I'm a huge fan of it, because you can just write your markup, you write your properties directly within the markup and your template, and you're done. And if you combine that with some kind of instant preview, you can really, really rapidly, very, very fast approach those things. The same for JavaScript. We put a data droopal selector, and then we put some LP in JS, like that. But all of those cases, we are manipulating the markup here directly, and that's pretty, pretty hard, because we tried that, and we learned that droopal is not really suited for the component, because it has historically been growing in a certain way. And as I already said, droopal six was pretty clean pre-process and clean input to a very clean template. But then some forms needed seeming, so we end up with the render arrays, and then later we did some more things. So I've tried several ways of re-implementing components within droopal in a much more simple way in the theme system. But what you quickly learn is that droopal kind of needs this complexity. I hear some quick syntax if you want to try to do something very react style in PHP, which looks very familiar to anyone that now is JavaScript in React. So as I said, Contrib needs this flexibility, because we need to enhance other modules and core via those mediation observers and the render array tree, et cetera. So do we need a PhD for droopal seeming? Some say so you do. Some say you don't. There's so many templates and templates in the best. There's so many things and hard to find things and seem suggestions help somewhat. But overall, it's complicated. And I hear from enterprise clients especially that they are like, it's a little bit complicated. We want to do things more react way, and that's where we come a little bit later too. So the droopal seeming state is neither easy, if someone disagrees, that's fine. But nor especially pleasant. And of course, there's certain people that just love it. That's exactly the right thing. But for the majority that I've spoken with it, they would love it to be a little bit more pleasant. So Component Library to the Rescue, it's the first module I want to show today. You overwrite any template in the system from the UI and break your site in the most simple way. There's no easier way. No. The ability to be able to really overwrite any template gives you a lot of responsibility too. And yes, right now, you're still able to break your site with Component Library. That's Component underscore library, the module. But it's overall working pretty, pretty well. So I don't think a demo will work with NPDF. No, it won't. What would have happened here is that we would have clicked this overwrite button, and then you would have taken this date. And we clicked the date, and we could select any template on the page. And graphically, we could then change the template, have some nice instant preview of how it looks, and then save it, and the date has changed. But another part that I want to quickly go in is some of the future very, very, very, very exciting work. And that is Workspaces and Component Library together with a little module called WSEconfig. It's probably one of the most underestimated Drupal modules that exist, Workspaces. Workspaces allows you to essentially create your content in a workspace, like Sandbox. And afterwards, you can publish all your content at once before no one is seeing this content, no one. And this is fantastic, because you can create editorial workflows. You can create approval workflows. You can create all kinds of things. Or even if you're just a single site user, hobbyist, whatever, you can just preview everything, change something on the home page, change some article, change some things. And with this, hopefully, also change your whole theme directly from the UI as a site builder, as a power user. And obviously, not everyone wants to give people that kind of power. But your mileage may vary in that. So yeah, redesign your whole site within the workspace, have someone else approve and preview it, and then push everything live when it's ready. And what's also possible with this Workspaces config approach is to give power users the ability to change the view within a workspace and then publish the view changes. So you get kind of like a little bit of revisioning for power users within Drupal. But all those that are just using config code and are like familiar on the command line, that's obviously not the way, but this is a way for site builders, power users, and editors. Decover Drupal and the admin experience. What is Decover Drupal? And now we have speed way up, so please be with me. The front end is powered by Wrekt. The Drupal only serves the data, no mark at all. So in a nutshell, the front end application is fully responsible for all rendering. And so we are avoiding the need for the Drupal to assume in PhD. Yay. The problem is Decover Drupal is great at theory, but hard in practice. Server-side rendering aliases, pages, menus, layout, but a paragraph. How do you get all of that done? There have been some great distributions created already, some great starter kits. There's always coming out new things, like Pension had just released some great Next.js starter kits to make it easier to develop things. There's Next for Drupal. There's several parts to make that easier, but it's still pretty hard in practice. And there's all that you lose. I've been originally a real opponent, as much as one can be an opponent of Decovered Approaches, because there's no contextual links, no local tasks, no admin bar, and no layout builder. What you see is what you get. Some we've gained back so far. So for example, with Next for Drupal, you have an iframe of the whole site. Then there can be different solutions with preview buttons to view specific sections. And some have built like placeholders for layout builder to kind of make it look like that. And some with the power of GraphQL have even already achieved the holy goal of rendering those GraphQL parts in a more true, what you see is what you get away. So what we did was we created SBA admin. The name is totally bad because SBA is single-page application, and this is for any Decovered application. But that was its original name that kept it for now. The HTML is mounted as usual. The Decovered application is then mounted to the main content. Then again, the Decovered application has a placeholder for Drupal content, and you just need to add one data attribute for adding contextual links. We gained back even more. We have now the admin bar back, contextual links, and we have placeholder for administrative links like edit. So, but like in the Decovered world, we also got all the problems back. So because now again, Drupal seems to be influencing the front end and the front end seems influencing Drupal. Fortunately, with many things like React, you have very, very scoped classes that are never conflicting with Drupal, or if you are using Tailwind, you also have probably, except for block, not really many conflicts. So there are definite ways around that, but yeah, the problems are definitely back. And it would be really cool if at some point we could put all Drupal admin interface like in web components, have some completely isolated from everything else, but that's still a future endeavor. What we still want to gain back is the navigation in Drupal. That means that you edit an article, you save it and then you come to note article title and you want to display it kind of like in the hybrid app, but you also want to keep like the action links, et cetera, layout builder in the Decovered theme. So what we need is a placeholder for entities and blocks. Now we get a little bit theoretical, but this is how it looks. So we have the admin bar, it's always present, and alone that is giving a great effect. We had a project where we prototyped the whole thing and we had the same theme once coupled and once decoupled. And people at some point got lost or am I in the Decovered or in the coupled theme because there wasn't that much difference anymore. And I think that this is what Decovered Drupal leads to look like, my opinion. So, but we still have the Drupal main content HTML, it's nicely within the Decovered application, it's below the Decovered menu, but we need this loaded via Ajax. So, what we do is we put a placeholder for the entity output. So essentially what SBA admin does, it puts like this little XD coupled component in, which is a web component. And this web component essentially then is again, going into React and React is then rendering the node. Finally, we are whatever means are set up for rendering nodes. And for implementing web components, the easiest is to just use pReact. Instead of React, which is a React flavor, but which is really great and which can be used for that. And sorry. And pReact is also some other advantage if someone is not having a JavaScript build system PhD, but still wants to use something modern like React that doesn't want to deal with all those setups, et cetera. Then a great combination is pReact and HTM because you can just include two libraries. It's like jQuery, like in the old days. And you can write your code directly in JavaScript, no build step needed. And you just reload your page and your changes are there. No hot reload, no nothing needed. You can add all of those if you want, but the simplicity can be there. So now that we have a web component, we have one problem. JSON API needs to know which fields to load. Because if you've ever worked with JSON API before, there's like a block and that block has like a field image, then that field image is not loaded automatically. And there's two ways to deal with that. The first is a component resolver. That's very simple. We're just mapping one content type to the other parts, whatever needs to be included. The other is something that I originally prototyped in the good old Drupal 7 days with services views. Someone had, funnily enough, the same idea with REST views. And we also created a module out of that. And that is called a JSON API field format. And JSON API field format, that's a new module, allows you to essentially use the power of U-Modes. Again, use what Drupal already provides. Use the UI to set up a server-side setup of how a very, very nice and clean output of this block, this node, this whatever is rendered. So here we are shifting again a little bit of the responsibility from the front end back to the back end to the biggest role, the site builder. And the site builder can then essentially say, hey, here's clean output for your front end. The front end can say, yay, I don't need to dig deep into JSON API structures and find all of those things. So that's a very nice thing. And it's fully spec-compliant because we're exposing it, we have a meter property. So once we want to go to the de-covered layout builder, there's a component resolver for blocks needed. So we do exactly the same as we did before. And now you can imagine you have like layout builder. And the layout builder has like all of those blocks like that. And now every one of those blocks is again, picking back into the React app and the React app is doing the final rendering. So you have the true what you see is what you get. And now to finally bring everything to the app, the only decision you need to make is do you want to cheat a little bit and allow Drupal to generate some markup with your styling in the app and then just replacing the placeholders to whatever components you want. Just need to pass the dome, replace the placeholders, load them all at once, and there you go. Or if you're wanting to pass what layout builder is providing the same markup classes and get that from the layout builder information. Yeah, so a demo coming soon for that. Follow TechOne consulting and at Fabian Fronts on Twitter. Coming later again. Next steps is a Next.js integration and the pure server-side rendering with P-react. Please also check out a new module, PageCacheBoost, because it allows you to do next-style revalidation without needing Next. Because I said if Next can cheat, we can cheat as well. Essentially, pages serve from the cache as stale for five seconds. Meanwhile, we generate it in Drupal using a terminate event and then send back with full-stamped production. I think the best approach architecture for a company that's Drupal-centric is where Drupal is serving the page and is essentially using Node-SSR, a farm of servers for rendering the HTML, but is serving it, is caching it, and is doing all the cache tag things and everything that's needed. And now there's a little approach that we don't have time for, but if anyone wants to know more, there's actually a pretty great way for doing something like Next does with SSG and SSR, but without all the complexity, you just define one data loader and you have full SSR loading with all resources loaded in parallel. It's pretty cool. Last thing for the last three minutes, Layout Builder Plus. Layout Builder and Core is you click at block, at new block, you click the block you want, you configure it in a text and configure, the block is placed. Layout Builder Plus. You open a site bar with all blocks to add. You drag the block you want to write section and it gets displayed with placeholder content and that's it. So you can very, very, very rapidly build layouts using drag and drop, which is really professional and nice. In fact, it's so nice that I never really want to build a site with Layout Builder because it felt always so cumbersome. And once I've seen that, I was like, wow, I really need to build a personal homepage just to use this tool. That's really cool. Yeah, again, a video won't work, but we also don't have time. So I treat the video out later on Twitter, uploading it to YouTube and then you'll have it. But yeah, thanks for Pex, who's in the audience. Usually this would have been such an amazing demo. You would all be applauding to him, but maybe you can do too. Pex, if you can quickly stand up. There he is. And thanks so much for all your hard work on that. Thank you for TechOne Consulting, for supporting and to our great clients who are open to those great ideas. It's definitely a dream come true for me, the Layout Builder Plus. Only limitation is right now, the focus is on reusable blocks because again, we are working at this workspace and workflow, but you can find it here, try it out and have fun. Thank you. I think we have one question. Yes, for sure. I'll be uploading the slides and again, you'll find them, I'll be posting them to Twitter, so you'll be able to download it. You'll have the videos included in them, so you can look at the demos in your laser. Yes, I don't know to what it was, but it's, I assume it's a decoupled part, but yes, it's working, it's perfectly working. There's no problems with that approach and with translations. Yes, it does work with dynamic content and caching. So it's not just for generating a static site that can also be done, but essentially when Drupal is the main page content provider, then it's okay. Can you, oh, Mike is working again. Okay, cool. We've so far added some custom block types, a slide and a hero, and that's pretty cool. And then we enable Layout Builder Plus. We also put those fields into special sections and we added some basic placeholder content. So now that we are almost set up and this runs three minutes, so we are adding a custom page after we, oh, one more block type. Okay, so list item and again here, the important thing is to select a section, Layout Builder Plus Aging and Enabling Layout Builder Plus. So saving that and then we are, oh, yeah, and if you put a required field and you don't put any default content, you will get like a nice shiny warning that Drupal will just provide it. And now finally after all of that, what we will be doing is we'll be enabling Layout Builder Plus for certain layouts so we can certainly restrict it to different layouts, saving that configuration. And now finally we are adding the Content Lending page. So Test Lending page, saving that, and now we come to the layout. And now what you probably have a hard time to see is there's a little button at the bottom here but it opens the sidebar and then you can add any blocks here, list item. And we want to make it that it's always open so you don't have to open it again and again. But yeah, you can just drag and drop but list item isn't allowed on that part so that didn't work. And we just put another hero. And then finally we can also use all of Drupal's blocks like the Allside By block and then it's asking you the configuration, you save it and that's it. So yeah, that's Layout Builder Plus.