Components everywhere! From Component Library module to Fully Decoupled Layout Builder with Instant Preview

[00:01:30] In Drupal, everyone is fighting modules, but one great thing about Drupal is that 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 that you didn't need to know how to code, you didn't need formal training, and you could still build yourself a site. That is really powerful. So all the modules I show today are hopefully empowering these site builders again.

[00:02:04] I want them to make better use of it, because I feel this is a part of Drupal that we as a community, and core especially, have neglected a little bit. In other areas we have obviously improved a lot, but there is always more you can do.

[00:02:26] So today's session is about components, a topic pretty dear to my heart, and I think it is a keystone for building sites without code. We originally started with a vision for components in Amsterdam in 2019, and we refined 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.

[00:02:56] Drupal 6 was already pretty close to components as they are used today in React and similar frameworks, because it was fairly pure, but we kind of lost that over time. So what is a component? A good example is a card: you have an image, text, and a call to action link.

[00:03:14] Components have one important property: they are independent. That means they are completely self-contained. All of the styling and interactivity is intrinsic to the component, nothing comes from the outside. The goal is that a component always looks the same way regardless of what you do around it.

[00:03:40] That is a really important property, and it is one of the reasons components are so great. Because of this non-interdependence, because they are confined to their own scope, you don't have to deal with so many side effects. In practical terms, a component is usually composed of HTML, some CSS, and some JavaScript.

[00:04:23] So, as normal, you have the HTML, the CSS, and the JavaScript. A component also has some kind of input, so it has properties that dictate what the component is displaying, and then in the end the children, the more complex content inside it. To give an example, a very simple component here is: my card, card equals card.

[00:04:56] A more complex example is a my-card where we give it a property of a red color, we put a card on it, and inside this component we put another component, which is a CTA component. With a simple component you could still have the my-card component output a CTA component, but this is just a slightly different way of doing things. One approach is slotting it in, and the other is essentially letting the component decide for itself what is happening.

[00:05:48] How do you reach that independence? There are different ways. One is BEM notation, where you define very specific classes that only apply to this component. In the front end world we also have styled components, scoped components, and several others, where you essentially use inline CSS or attach CSS directly to your component and the JavaScript framework does some magic to apply it.

[00:06:14] For a more pure Drupal, back end way, we have the ability to define classes like card and card title, and we have the ability to define Tailwind CSS parts. Tailwind CSS, if you haven't heard of it, is very dear to me. I really love it, and I'm a huge fan, because you just write your markup, you write your properties directly within the markup and your template, and you're done. If you combine that with some kind of instant preview, you can approach these things really rapidly.

[00:06:54] The same goes for JavaScript. We put a data-drupal-selector and then some Alpine.js, like that. But in all of those cases we are manipulating the markup here directly, and that is pretty hard, because we tried it and we learned that Drupal is not really suited for components. It has historically grown in a certain way.

[00:07:27] As I said, Drupal 6 was pretty clean: clean preprocess and clean input to a very clean template. But then some forms needed theming, so we ended up with render arrays, and later we did some more things. So I have tried several ways of re-implementing components within Drupal in a much simpler way and theme system, but what you quickly learn is that Drupal kind of needs this complexity.

[00:07:54] Here's a quick syntax if you want to try something very React-style in PHP, which looks familiar to anyone who knows JavaScript and React. As I said, Drupal needs this flexibility, because we need to enhance other modules and core, we have those mutation observers, the whole render tree, and so on.

[00:08:18] So, do you need a PhD for Drupal theming? Some say so, some say you don't. There are so many templates, and templates within templates, so many things, and it is hard to find things. Theme suggestions help somewhat, but overall it is complicated. I hear from enterprise clients especially that it is a little bit complicated, and they want to do things in a more direct way, which is where we come in a little later.

[00:08:56] So the state of Drupal theming is neither easy, if someone disagrees that's fine, nor especially pleasant. Of course there are certain people who just love it, and that is exactly the right thing, but the majority I've spoken with would love it to be a little more pleasant.

[00:09:14] So, Component Library to the rescue. It's the first module I want to show today. You can override any template in the system from the UI, and break your site in the most simple way. There is no easier way. Being able to really override any template gives you a lot of responsibility too, and yes, right now you are still able to break your site with Component Library. That's component_library, the module. But overall it is working pretty well.

[00:09:57] I don't think a demo will work within a PDF, and no, it won't. What would have happened here is that we would have clicked this override button, taken this data, and clicked the date. We could select any template on the page, graphically change the template, get a nice instant preview of how it looks, and then save it, and the data has changed.

[00:10:33] Another part I want to go into quickly is some of the very exciting future work, and that is workspaces and Component Library together with a little module called WSE Config. It is probably one of the most underestimated Drupal modules that exist. Workspaces essentially lets you create your content in a workspace, like a sandbox, and afterwards you can publish all your content at once. Before that, no one is seeing this content, no one.

[00:11:15] This is fantastic, because you can create editorial workflows, approval workflows, all kinds of things. Or even if you are just a single-site user or hobbyist, you can preview everything: change something on the home page, change an article, change some things, and hopefully also change your whole theme directly from the UI, as the site builder or power user.

[00:11:45] Obviously not everyone wants to give people that kind of power, so your mileage may vary. But yes, redesign your whole site within the workspace, have someone else approve and preview it, and then push everything live when it's ready.

[00:12:07] What's also possible with this workspaces config approach is to give power users the ability to change a view within a workspace and then publish the view changes, so you get a little bit of revisioning for power users within Drupal. For those who are just using config in code and are comfortable on the command line, that's obviously not the way, but this is a way for site builders, power users, and editors.

[00:12:41] Decoupled Drupal and the admin experience. What is decoupled Drupal? Now we'll speed way up, so please bear with me. The front end is powered by a JavaScript framework and Drupal only serves the data, no markup at all. So in a nutshell, the front end application is fully responsible for all rendering, and we are avoiding the need for duplicate templating in PHP, yay.

[00:13:06] The problem is that decoupled Drupal is great in theory but hard in practice. Server-side rendering, aliases, pages, menus, layout, paragraphs, how do you get all of that done? There have been some great distributions and starter kits created already. There's always new things coming out, like Pantheon just released some great Next.js starter kits to make it easier, there's Next for Drupal, there are several parts to make it easier, but it is still pretty hard in practice.

[00:13:38] And that's all the stuff you lose. I was originally a real opponent, as much as one can be an opponent, of the decoupled approaches, because there are no contextual links, no local tasks, no admin bar, and no Layout Builder. What you see is what you get. Some of that we've gained back so far. For example, with Next for Drupal you have an iframe of the site, there can be different solutions with preview buttons to view specific sections, and some have built placeholders for Layout Builder to make it look like that. Some, with the power of GraphQL, have even achieved the holy goal of rendering those parts in a true what-you-see-is-what-you-get way.

[00:14:22] So what we did was create SPA Admin. The name is bad, because SPA is single page application and this is for any decoupled application, but that was its original name so we've kept it for now. The HTML is rendered as usual, the decoupled application is then mounted to the main content, and the decoupled application has a placeholder for Drupal content. You just need to add one data attribute to get contextual links.

[00:14:52] We gained back even more. We now have the admin bar back, contextual links back, and placeholders for administrative links like edit. But, as in the coupled world, we also got all the problems back, because now again the Drupal theme is influencing the front end and the front end theme is influencing Drupal. Fortunately, with things like React you have very scoped classes that never conflict with Drupal, and if you are using Tailwind you also have few conflicts, except perhaps for Block. So there are ways around it, but the problems are definitely back.

[00:15:34] It would be really cool if at some point we could put the whole Drupal admin interface into web components, completely isolated from everything else, but that is still a future endeavor. What we still want to gain back is navigation in Drupal. That means you edit an article, you save it, and then you land on the node article title and want to display it, like in a hybrid app, while still keeping the action links, Layout Builder, and the decoupled theme.

[00:16:07] So what we need is a placeholder for entities and blocks. Now it gets a little theoretical, but here's how it looks. We have the admin bar, which is always present, and that alone already gives 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: am I in the decoupled or the coupled site? There wasn't much difference anymore, and I think that's what decoupled Drupal should look like, in my opinion.

[00:16:41] We still have the Drupal main content HTML sitting nicely within the decoupled application, below the decoupled menu, but we need it loaded via Ajax. So what we do is put a placeholder for the entity output. Essentially, SPA Admin puts a little web component in, and this web component then goes back into React and renders the node via whatever means are set up for rendering nodes.

[00:17:22] For implementing web components, the easiest is to just use Preact instead of React, with the React flavor, which is really great and can be used for that. That's another advantage: if someone doesn't have a JavaScript build system PhD but still wants to use something modern like React, without dealing with all those setups, a great combination is Preact and HTM. You can just include two libraries, like jQuery in the old days, and write your code directly in JavaScript, no build needed. You just reload your page and the new changes are there. No hot reload, nothing needed. You can add all of that if you want, but the simplicity can be there.

[00:18:21] Now that we have a web component, we have one problem: JSON:API needs to know which fields to load. If you've ever worked with JSON:API before, there's a block, and that block has a field image, but that field image is not loaded automatically. There are two ways to deal with that. The first is a component resolver, which is very simple: we just map one content type to the other and whatever needs to be included.

[00:18:54] The other is something I originally prototyped in the good old Drupal 7 days with Services Views. Someone had funnily announced the same idea, which was Rest Views, and we made a module out of that, called JSON:API Field Formatter. It's a new module that lets you use the power of your view modes again, use what Drupal already provides, and use the UI to set up a server-side definition of a very clean output of a block, a node, or whatever is rendered.

[00:19:32] So here we are shifting a bit of the responsibility from the front end back to the back end, to the site builder. The site builder can then say, hey, here's clean output for you, front end, and the front end can say, great, I don't need to dig deep into JSON:API structures to find all those things. That's a very nice thing, and it's fully spec compliant, because we're exposing it via the meta property.

[00:20:02] Once we want to go to the decoupled Layout Builder, a component resolver for blocks is needed, so we do exactly the same as before. Now you can imagine you have Layout Builder with all of those blocks, and every one of those blocks is again piggybacking into the React app, and the React app is doing the final rendering. So you have the two, what-you-see-is-what-you-get.

[00:20:31] To finally bring everything into the app, the only decision you need to make is whether you want to cheat a little and allow Drupal to generate some markup, which you style in the app and then just replace the placeholders with whatever components you want. You pass the DOM, replace the placeholders, load them all at once, and there you go. Or, if you want, you can pass what Layout Builder provides, the same markup and classes, and get that from the Layout Builder information.

[00:21:02] A demo is coming soon for that, so follow Tag1 Consulting and Fabian Franz on Twitter, coming later again. This is an Astro integration and pure server-side rendering with Preact. Please also check out a new module, Page Cache Boost, because it lets you do Next-style revalidation without needing Next, because I said if Next can cheat, we can cheat as well. Essentially, pages are served from the cache, stale for five seconds, meanwhile regenerated in Drupal using a terminate event and then sent back, with full stampede protection.

[00:21:43] I think the best architecture for a company that is Drupal-centric is where Drupal is serving the page and essentially using Node SSR, a form of server-side rendering, for the HTML, but it's serving it, caching it, and doing all the cache tag things and everything that's needed. There's also a little approach we don't have time for, but if anyone wants to know more, there's a pretty great way to do something like what 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.

[00:22:29] Last thing, for the last three minutes: Layout Builder Plus. In Layout Builder in core, you click add block, add new block, click the block you want, configure it in a dialog, and the block is placed. In Layout Builder Plus, you open the sidebar with all the blocks to add, you drag the block you want to the right section, it gets displayed with placeholder content, and that's it. So you can very rapidly build layouts using drag and drop, which is really professional and nice.

[00:22:59] In fact, it's so nice that I never really wanted to build a site with Layout Builder before, because it always felt so cumbersome, but once I saw this I thought, I really need to build a personal homepage just to use this tool. That's really cool. Again, a video won't work, and we also don't have time, so I'll tweet the video out later on Twitter and upload it to YouTube, and then you'll have it.

[00:23:29] Thanks to Pax, who's in the audience. Usually this would have been such an amazing demo that you would all be applauding him, but maybe you can applaud Pax now, if he can quickly stand up. There he is. Thanks so much for all your hard work on that, and thank you to Tag1 Consulting for supporting this, and to our great clients who are open to these great ideas. It's definitely a dream come true for me, the Layout Builder Plus.

[00:24:00] The only limitation right now is that the focus is on reusable blocks, because again we are working with workspaces and workflow, but you can find it, try it out, and have fun. Thank you. I think we have one question.

[00:24:19] (Question from the audience.) Yes, for sure, I'll be uploading the slides, and you'll find them. I'll be posting them to Twitter, so you'll be able to download them, and the videos will be included, so you can look at the demos at your leisure.

[00:24:41] (Question from the audience.) I don't know exactly what that was, but I assume it's a decoupled part. Yes, it's working, it's working perfectly, there are no problems with that approach with translations.

[00:24:58] (Question from the audience.) Yes, it does work with dynamic content, so it's not just for generating a static site, though that can also be done. But essentially, when Drupal is the main page content provider, then it's fine. Thank you.

[00:26:34] Can you... oh, the mic is working again, okay, cool. So far we've added some custom block types, a slide and a hero. That's pretty cool, and then we enabled Layout Builder Plus. We also put those fields into special sections and added some basic placeholder content.

[00:27:02] Now that we are almost set up, and this runs for three minutes, we are adding a custom page. One more block type: a list item. Again, the important thing here is to select a section, and then enable Layout Builder Plus. So I'm saving that.

[00:27:30] And if you put a required field and don't provide any default content, you'll get a nice shiny warning that Drupal will just provide it. Now, finally, what we'll be doing is enabling Layout Builder Plus for certain layouts, so we can restrict it to different layouts. Saving that configuration, and now finally we are adding the content, a landing page.

[00:28:00] So, test landing page, saving that. Now we come to the layout. What you probably have a hard time seeing is that little button at the bottom here, but it opens the sidebar, and then you can add any blocks here, a list item. We want to make it so it's always open, so you don't have to open it again and again.

[00:28:27] You can just drag and drop, but list item isn't allowed on that part, so that didn't work, so we just put another hero. And then finally we can also use all of Drupal's blocks, like the Views block, and it asks you for the configuration, you save it, and that's it. So yeah, that's Layout Builder Plus.