 Hi, Drupal Gov. I'm Brian Gilbert, the founder of Reality Loop, a Melbourne-based Drupal development shop. I've won many hats in my Drupal journey, larger developer, core contributor, community lead, event organizer, trainer, and more. Today I'll be playing the part of an interviewer. I have with me Stuart. Can you please introduce yourself and tell us what you'll be talking about? Hi, I'm Stuart Clark. I'm the lead developer at Reality Loop. I am a decoupled Drupal and Vue.js developer, and I'm the creator of Truxt.js. Today I'm going to show you how to decouple Drupal using Nuxt.js and the Truxt site module. But before we get into that, could you quickly cover off what decoupling is? Decoupling is the process of separating your presentation layer or your front-end from your content management system, your back-end, in this case, Drupal. Okay, so using Drupal more as a content repository? Yeah. And why would I want to do that? You might want to do it for multiple reasons. I think one of the most important reasons is that your content can power more than a single site. You can have your public website, but in addition to that, you may have an intranet and multiple campaign sites, native applications, voice assistants, the theming experience. PHP is a great language, but front-end development and developers tend to prefer a JavaScript-based language for the reactivity and component-based languages like Vue.js. So decoupling gives us more options and allows developers to work the way they prefer, making it easy to find developers. Why isn't everyone decoupling? There are valid reasons why not to do it, and I think one of those is the complexity. When we first started decoupling our websites, there was a lot that had to be reinvented, so that's also where DrugsJS comes in. How would we go about decoupling with Drupal? It's relatively simple. Both Drupal 8 and 9 come with the JSON API module, which does the majority of the work. We're also going to be using the JSON API views module and the DrugsJS module, which simplifies some of the setup process. The Drugs module also provides a read-only permission that allows you to control who has access to all of the required JSON API resources. What does the JSON API module give us? The JSON API module provides a way for a front-end or a JSON API client to consume the site's content as well as some configuration in a standardized format. What do we have to do to start on our front-end? For the front-end, we're going to use Nuxt. Much like Drupal is a PHP framework for your back-end, Nuxt provides you with all the things that you want for a modern Vue.js site. Why are you installing DrugsSite here? Drugs is a modular framework. It allows us to build lots of things using Drupal's content and Drupal's configuration. DrugsSite is more focused. It's about providing that out-of-the-box front-end experience. So I'll jump into the configuration. If we open up the Nuxt config file, all I need to do is add the DrugsSite module and our Drugs configuration, which is just the base URL, the domain for our back-end. We'll also go ahead and set up the Nuxt proxy so that our images will work correctly. And lastly, I just need to set the components directory to global for Drugs's theming system. And that's it. I'll spin that up and we can take a look here at our Nuxt application and that's building the bundles required to serve up our front-end. And where's this page come from? If we just jump across, you can see here is the index page and that's being served via Nuxt, not via Drupal. So we could create files here if we wanted to have one-off campaigns or standalone applications that are alongside the site. Yeah, this demo here, we don't need that. So we'll just go ahead and delete that. Now we can see content from the Drupal back-end. Could you explain what's going on internally? I think the best way to do that is if I open up the view developer tool, we have a layout provided by Nuxt. It's layout system which allows us to wrap the entire application with the required markup. So it's kind of like page TPL in Drupal? Yeah, if we step through, we can then see our Drugs router component. It communicates with the decoupled router in the back-end to determine what this particular page should be rendering. So in this case, we're rendering the front-page view. As you can see here in Drupal's back-end, this is the view. We're actually now passing on to a Drugs view component which has got access to all of the results for that view. Do we also get the view header and attachments? Yeah, so that information is provided in the view resource. Okay, so how do we theme that? Theming in Drugs is relatively straightforward. It uses a slot-based theming system. So we can just take one of these available options and drop that into the components directory. And then we render out our slot, and that's the content provided by the Drugs view component. It also has name slots so we can render out the header and the results separately. The Drugs components also have a wrapper property which here allows us to set the component, props data, and the class that wrap our result entities. I see these items, our entities coming back from the view. What's defining the display here? Drugs leverages Drupal's own display system. If we have a look at the back-end here, you can see... It only shows the image. Yeah, exactly. You can make changes in your back-end and Drugs will respect that. That's great, but what if I just wanted to add it in the component? The parent component also provides props data. In this case, entity fields and schema. We simply need to register the required props in our component, and then we can reference it in our ViewJS expressions. You mentioned campaigns earlier. Could we see an example? Sure. This is a campaign I set up on our Umami demo site. To get started, you just need to create a file in the Nuxed pages directory. What are those B tags you're using here? They are layout components from the Nux Bootstrap View module, but you can build this any way you like. Any NPM library can be used, the View YouTube component for instance, which I could have used in this demo, but instead I used the embed code. So, does that mean it's possible to use Drugs components in a page? Yes, absolutely. All Drugs modules can be used via the Drugs component itself. It just needs the module name and the correct properties, which we can find in a few different ways. One way is to use the View developer tools, as I've done here. Alternatively, you can read the output of the JSON API directly. Earlier you mentioned using Drupal content in other applications. Do you have anything you can show? This is an example entity explorer app, which allows us to see all of our content in any chosen View mode. We designed it to help with the process of populating the campaign page. It also has a way to test and demonstrate our theming changes against live data. You can have a look at the source code for this in the Umami demo repository on GitHub. It looks like Drugs is pretty mature already. What's the status and current roadmap? There's still a lot to be done. Our target for a 1.0 release is a feature parity with the Drupal Umami demo. But to get there we need to engage with the communities, back-end and front-end alike, which is part of the reason for this presentation. What sort of contributions are you looking for? All contributions are welcome, of course. The more eyes on the project, the better it becomes for everyone. Documentation, testing, feature requests, support queries help a lot, as do pull requests. The project is open source, and while Reality Loop is currently funding my development time, there will be a point where the project will also be looking at options for funding. That leads on to how can someone actually get involved? You can find the code and issue queues on GitHub, and for support and general inquiries, you can find us on the Community Discord server. We're also available in the Drupal Slack. Thanks for your time, Stuart. Let's cut to questions now. You can put me live, I think. If we have any questions, please feel free to post them now. We've got one from Seagull, which is how SEO-friendly is Drupal JS? Sorry, DruxJS. That's a good question. Can we get my video full screen? It is, Stuart. It is? I'm in preview at the moment. It's as SEO-friendly as NuxJS is, so Drux is just a layer on top of Nux. There is already a range of modules available for SEO in Nux. Are you aware of any similar systems? How does Drux compare to other things? There are another few sets of tools similar to Drux. We saw some at Drupal Con Global earlier this year. We're not really the right people to make that comparison, but we would like to see people doing that, people who have tried each of the individual solutions. The main thing about Drux is it's not about replacing a solution. It's not about being the only one thing. It's written in such a way that the modules can be used with existing solutions. Drux is primarily of UJS, but the schema module, for instance, could be used with React quite easily just by including in the relevant classes and taking advantage of that logic. I've got a question from Lee. Does the markup come from Drupal when you use Drux Entity? When you use a Drux Entity, the markup doesn't necessarily come from Drupal, but this schema does. Drupal will tell the front-end, the Entity module, via the schema that, say, three fields are showing. The image field, the body field, and another field. It'll say what order that those fields should be shown. Then Drux will pass that through to the relevant field. Those fields are provided in the Drux Entity module. There's a bunch of... Let me see if I can jump across to a quick example. Give me a second. If you have a look at the Drux Entity module, you'll see that this comes with a bunch of fields, such as basic string, date time, entity reference. Each of these fields are being provided with the Drux Entity module. Additional could be added in the future, but these are your bare-bone base fields. They will take the data from the JSON API resource and the schema information that they've been passed, such as the settings for that particular field, the view mode for the reference field. They will pass that to the field, and it will then determine what to render. Tim asked, I'm going to paraphrase, because for what I think, which is how do relationships work, e.g. reference entities in Drupal? Yeah, so they work. It was built out of the box to work with paragraphs for our preferred setup. The way it works is probably best if I actually jump in. Is my screen viewable to everyone? Yes, too. Okay. If I jump into this here, and we open up a piece of content, so I'll jump into an entity. Let's see. What am I looking at? This one. All right. So that goes through to a themeable component here, DrugsEntityCardCommon, which passes through to a field. And in this case, that field is an entity reference field. So if we open that up, you can see that the entity reference field actually passes its information along to another DrugsEntity. So it's doing that entity reference exactly the same way that Drupal would. And then Drupal will then pass that along to its relevant field, and then you come to the last field in the RenderStack. Okay. Is there any PIP projects that you're using Drugs on? Yes. We, myself and my wife are currently building a game with it, using Drupal as the back-end, the database. And essentially, you have your Drugs front-ends where you'll present the game. You have web sockets to communicate with each player, and then it just stores that data as you play the game in Drupal and syncs it across and allows you to play another game. So it's a multiplayer game, basically similar to Cards Against Humanity style. You'd be in the same room. You'd be synced up with all the players that are in there. Marco asks, can you use Drugs.js in a progressively decoupled approach, like an on-page mini app slash widget? I don't see any reason why you wouldn't be able to. So each of the modules provide different exports as is. So if we were to look at... I'm still in here. One second. If you look at the component, the Drugs entity component, so as long as this entity component is registered in your progressively decoupled site, it will be available to your progressively decoupled view app. Drugs uses a Vuex store for the data that it has available to render into those components. But there's no reason that shouldn't work with progressively decoupled. I have not tried myself personally though. Letan asks, why did you choose Drupal as a database for the gaming site you're developing? I chose Drupal because I'm building Drugs. The main reason is as I started developing Drugs and I can see the connection, the ability to use data and crunch that data with things like views, I can simply turn Drupal into a database. It holds the information. It can crunch it. It can do whatever I need, but it's not necessarily for display. The front end, the Drugs side of things, it can just pull that data, the information I need and figure out what it wants to do with it instead of leaving that up to Drupal. Jack's asking, do you see any alternatives for paragraphs to model data for decoupled sites? It's an age old question. I don't want to make that decision. I don't want to use paragraphs in reality loop builds that we do. Any entity reference that you use, any entity referenceable system that you use will work with Drugs at the moment because the whole point is do what Drupal expects you to do. An entity reference says, this is my connection to other data and Drugs will go, I see your connection. I will acknowledge it. If you were using a WYSIWYG based approach, it will get the data that the Drupal has stored sent to you. So if you've got your references tokenized inside of that data, Drugs will see it and you will be able to use Drugs to reinterpret it as need be, but references and paragraphs seem to be the most logical for data structure. Are there any types of site that Drugs isn't currently suitable for? At the moment, the Auth module has not yet been solidified and published. So a site that is heavy on Auth is not the best choice right now, but it's essential. We're aiming at the moment to build Drugs around the UMami demo because it is a... On interrupt, we've only got 30 seconds left. How about integrating with something like Sol or other search engines? Yeah, absolutely. If you're headless, if you're decoupled, you can integrate with anything that you need to. If you've got endpoints, you can do it. The version of a front-end that we have with something similar to Drugs goes straight to the search engine instead of going to Drupal. In the case of the UMami demo, the search work that has been done to this point goes to Drupal via the JSON API search module and then to the search system. Okay, that was it. Thank you for being here and we'd love to hear feedback. Please jump into the Discord channel if you have any more follow-ups.