 Yes. How about now? That's much better. From the second I started to breathe, I could tell it was on. Okay. Is this good volume? Yes. All right. In terms of the people running the show, I don't need to press anything to record. Right? Just start presenting. Where did he go? I believe I don't. So, I think we can get started. All right. Hello, everyone. Thank you for joining us. Today we're going to be talking about we're going to be talking about progressive decoupling. Talk title is progressive decoupling best of both worlds. And we're really going to focus on some of the key benefits of progressive decoupling and we're going to compare and contrast with similar approaches with regular old Drupal. I say that lovingly. And with fully decoupled Drupal as well. Okay. So, I will introduce my co-speaker, Amani, because she's a little too humble. She is a Drupal architect. She's been working in Drupal for quite a while now. After initially going through our course at Debug Academy, one of my claims to fame is that she's one of our graduates. And I've been working with her for a while now. She's great at Drupal. She's not as great at soccer. Sometimes I feel like her feet are decoupled from her head. We're on a soccer team together. Friendly banter, don't worry. But yes, I expect similar praise for my soccer skills. Okay. I just want to say I scored the first goal for the season. So, thank you. Thank you. I think my part is that I set the tone for success. If people can't keep up, it's not my fault. But what I can say about Ashraf is he is a really great Drupal teacher. And a lot of people have taken his three month Drupal course and have become mid-level and senior Drupal developers. He's been a great mentor and he's worked on very high profile websites. He's also an Acquia triple certified Drupal expert, which he loves for us to comment about because he's very humble himself. I guess it's pretty impressive. But yeah, we're excited to go over this topic with you all on progressive decoupling. Today we'll talk about what progressive decoupling is, when you should use it, some of the key benefits to using it, and how to create and integrate decoupled apps within your Drupal website. Sorry, I'm like trying to figure out the cursor here. Okay. There we go. Okay. So, progressive decoupling is when you continue to use Drupal's front end and a JavaScript framework as needed. So, a lot of us are familiar with fully decoupled or headless Drupal, which is when you replace Drupal's entire front end with a JavaScript app. And in this case, Drupal serves as a content repository, providing content via API endpoints and as a content administration tool, where editor and back end pages can still be used. With progressive decoupling, you get to continue to use Drupal's front end and you can enhance it, and there are varying degrees of progressive decoupling. So, you can decouple a specific field within a form such as a multi-select form widget, or you can decouple an entire form itself. You can decouple a specific block or a page. I had a situation, this was a few years ago where I had a views list that was using the Views Infinite Scroll module, and at the time, there was a bug in the module that was causing duplicate items. And none of the standard ways that you would fix it in Drupal by using aggregation settings or setting query distinct or fixing it. And it was a well-documented issue in the issue queue, and there wasn't really a good solution for it. And at that time, I also wanted to gain some experience with React, so what I did is I decoupled a block, so I created the list of articles and used a React component to do the Infinite Scroll functionality. So that's just an example of how you can solve a problem by using a decoupled approach. So, when you should progressively decouple depends. It depends on your team's comfort level with Drupal theming and module development, as well as their comfort level with a JavaScript framework such as React or View. So, the lower their comfort level with Drupal theming and module development and higher comfort level with a JavaScript framework that increases the benefit to doing some decoupling. Also, it depends on your project needs, so the more UI interactivity, the more complex forms that increases the benefit to using decoupling. There are some signs that you can look for where decoupling can be beneficial. So, if you have a lot of nested paragraphs for the sake of user experience, you could take a decoupled approach and improve the user experience while also reducing the risk of loading your database by using paragraphs because it's another revisionable entity. Also, if there's a lot of Ajax on your website, for example, with multi-value fields, you always have that button like add another element and another item. And so, when you have Ajax, it's doing another page request. But to load another text field shouldn't require another page load. So, if you use a decoupled approach, React would just load the markup and it would be faster for the end user. Another example would be if you have to deal with a lot of complex render arrays. So, this can happen with nested entity forms. And I'll actually go through an example in the upcoming slide. But essentially, if you use React, you have full control of the data and how you store it before submitting it, which makes it a lot easier than dealing with the render arrays. And then also with, if you have a lot of page refreshes, such as with multi-step forms, you can choose a decoupled approach which would, because the React application is downloaded upfront, it would just load the next set of markup right away and that would be a perceived performance gain to the end user. And lastly, with unintuitive field widgets, if you want to replace some of Drupal's field widgets with React components to enhance the user experience, that's another opportunity for some progressive decoupling. Okay, so we had a client where, building their website, it required that we nested an entity form within another entity form. And we used the inline entity form module to improve the user experience of the field that was referencing the nested entity form. And this all worked well and accomplished what the client had asked for. But later on, the client asked for a new feature which would require a field on the parent form to influence the drop-down options of a field within the nested entity form. And I thought it would be doable. I thought it would be pretty easy because I was very comfortable with hook form alter. But with inline entity form, it actually uses its own hooks and it wouldn't let me get the form state values of the parent form. And this was actually an issue in their issue queue that hadn't been resolved. So, sorry I went... Yeah, okay. So what we ended up having to do we continued to use the original form and remove the inline entity form module and recreated its functionality in a custom module. We had to manipulate the complex render arrays to get the functionality that the client wanted. But we were able to do it. I can show you the end result. So this is what our form ended up looking like. And so the design is okay. It's acceptable. And the client is really happy with it. And if you see the selected diagnosis field, that's the field from the parent form. And the treatment type form field at the bottom is the field from the nested entity form. So based on the diagnosis, a user selects should determine the treatment type options that are available. And so we were able to do that functionality and the client is happy with it. But it is harder to maintain. So in hindsight, we would have actually chosen to decouple the entire form because we would have had control of how we could pass values from field to field more easily. In addition, we would have had access to react components that would have been more intuitive and could have made the design of the form even better. And when you submit the form, because we have control of the field data, we could reformat it however needed for the Drupal API endpoints. And so this is just an example of how in hindsight we could have actually used progressive decoupling to make our lives easier as developers to make it easier to maintain, but also providing an even better user experience. So a lot of times people ask the question whether they should decouple or not, and they're mostly talking about fully decoupling. Some things you need to consider is when you fully decouple, you're replacing Drupal's entire front end, which means that you're going to lose a lot of the functionality that we sometimes take for granted for, and you'd have to implement it when you do fully decouple. So some of that includes Drupal's accessibility and SEO work, the node preview functionality, the login and authentication. Another thing you have to consider is that visitors can visit and filter API endpoints directly. So if you have a page where you're showing a list of articles, and you have the filter option set to type equals physical, and limit equals 10, if a user inspects your page, they can grab the API call and change type equals page, or limit equals 15. And so that's just something that you'd have to be mindful of site-wide when you do a fully decoupled approach. And then also it is difficult to reverse core, so if you commit to it, it's kind of an all-or-nothing approach. Okay, so why bother decoupling at all? Because there's a compromise. You can progressively decouple. So you can use React component libraries, and I know there's other options. You could do View, Next.js, but I'm more used to React, so I'm using it as the example. But essentially you can replace Drupal core's widgets with better React components. You can have an easier time customizing forms so that you don't have to deal with render arrays. And oftentimes these component libraries are easy to install and set up. And the idea here is you get to keep the benefit of Drupal's front-end while still having the flexibility to improve your user experience and performance by progressively decoupling. So these are some of the component libraries that you can use. I was going to show you this, which is just a Drupal Omami website. These fields, the restaurant dishes, and the cuisine are both taxonomy term reference fields. And restaurant dishes, they're both multi-value. This one, the widget is select list, and cuisine is obviously using check boxes. So with restaurant dishes, the issue here is that it's not very intuitive that you can select multiple options. And to do so, you would have to hold the standard control button on your keyboard. And with cuisine, if you had a long list of options, check boxes wouldn't be the best user experience. You could decouple those fields. And this is using the material UI React component library and you have options. So this is just a standard select list. This doesn't really, to me at least, signify multiple values can be selected. But if you go down here, you have a drop down list with check boxes, which is probably what I would choose for those fields. In addition, so sometimes we do our taxonomy term reference fields as auto complete. But the user doesn't know what to search for. They don't have a list. So you can use one of these React components and select. So if I do the Godfather, and then I actually search for it again, oh, I think you could see that here, you could X out one or all. This is the one I actually wanted to show. Whereas you can select the Godfather and then when you search for it again, the only option here is the Godfather part two because it filters out the selected options that the user already selected, which is kind of nice. A Drupal option to improve the UX of the reference fields would be the chosen module, which is a good option and out of the box is easy to set up. But with decoupling, you get variations and options to select from that have additional functionality. So the fact that this filters out options already selected or the fact that you can X out an individual or clear the whole item list is beneficial and just makes it a little more intuitive and friendly to the user. So yeah, those are just some examples of how you can improve the user experience by decoupling field widgets. And now I'll pass it to us, Chef. Thank you. Alright. Yeah, so like she said, she was showing some of these component libraries that can be used to improve things quite a bit. I'm going to talk a bit more about the how, sort of like implementation and comparing the fully decoupled and the progressively decoupled implementations So yeah, let's talk about how we can benefit from all those component libraries out there. So we're not just stuck with the one or two options, widget options that Drupal gives us out of the box. So to sort of compare and contrast with fully decoupled, there's sort of three areas you need to focus on building. First of all would be the back end. In a fully decoupled setup, the administration interface and the editor experience, they tend to remain unchanged for the most part. People still log into Drupal, they still use the node add form, the node edit form and so on. But we don't use Drupal's theme for the end user, for the visitors of the website. Instead, in Drupal we would have to expose the content as an API. So you can do that using Core's JSON API module, you could alternatively do that using the contrib graph QL module. Now the difference between the two, JSON API will, the API endpoint and the structure of those APIs will closely resemble the schema of the entities. So if you had something like a content type with a paragraphs field, then the API endpoint would look something like node ID, it would have something like field paragraphs and it would have a tree of the entity IDs of each of those paragraphs and then if you actually wanted the content from the paragraph, you might need to fetch the IDs and afterwards you'd have to fetch the paragraphs from the paragraph specific endpoint. So again, it matches the structure of the actual entities quite closely. If you wanted something maybe a little more intuitive for your front-end developers, you could use GraphQL, which allows you to essentially customize those API endpoints. So you can say, I don't want to show field paragraphs and then the entity ID of my paragraph, I want to show the actual title from that paragraph directly in the same API response. So GraphQL allows you to essentially customize your API endpoints, choose what gets in there and where it goes, what the labels should be, what the structure should be. So it lets you do more setup work there to simplify things for yourself and your front-end developers if they're not the same people. There are frameworks out there. Contenta is one that a lot of people really liked and it's a Drupal framework which focuses on simplifying the fully-decoupled setup. So if nothing else, it's a good place to look for learning how they approached different things. So that slide is really just about if you're doing fully decoupled, one of the steps is setup Drupal's back-end and expose your content as API endpoints. Another step is of course the front-end. So you would use something like React. We're using React as the example, but like she said, you could use ViewJS or some other option as your front-end. So you would use React. Let's say you're using React to build your full front-end. React actually recommends using another JavaScript framework alongside it. So they recommend using NextJS for routing or remix or Gatsby alongside React. Because React primarily is a component library framework. It's really good at giving you components that work well, that look good, and that are very smooth and interactive. But React doesn't give you routing out of the box. So they recommend integrating another library. So as part of your fully-decoupled setup, that's something you have to figure out. Do I want Next, Remix, Gatsby, or do I want to just use React and just figure out the routing logic and the meta tags and everything else, figure those out myself. And with whatever component library you pick, whatever framework you pick, you also are going to have to make sure that you're implementing accessibility properly and SEO and so on and so forth. It's possible that you pick a component library where the components themselves are not accessible. So that is something you need to watch out for. Okay, and the third piece of the puzzle is integrating the frontend and the backend. One of the first things you're likely to run into is cores issues. When you have your frontend, let's say on one server and you have your Drupal site on another server, and you try to make API calls from your frontend to your Drupal site, most likely your browser is going to reject it and say, error, cores, configuration. And so in Drupal, you can configure that. That's something you'll have to take care of. This picture, just to give proper credit on the right, this picture is from Contenta's documentation. But yes, you'd have to configure that to ensure that your frontend is able to get through to those API endpoints. But also you actually now have to worry about caching two different applications. So Drupal has its whole caching system, caching setup. If you host Drupal on any of the popular well-known hosts, most likely you're going to have varnish caching as well as a CDN. So CDN is going to cache ideally your fully built Drupal pages. But in this case, your fully built Drupal pages are actually your API endpoints. So that's what the caching is going to impact. But you have two applications in a fully decoupled setup. So now you also have your frontend with its own CDN and its own caching logic. And so you have to be sure that you're aware of an edge case, which is let's say you delete a field from your content type, or you add a field to your content type. And that should affect both applications, right? So I add a field to my Drupal content type, I delete another field at the same time, I publish my Drupal app, and now my app is updated to call this updated API endpoint, which would be at the same URL, but it would now have a different structure. If a user visited your site yesterday, their browser may have cached the React application, the entire thing, because it's just a JavaScript file. And so they reload your website, their browser says, hey, I got this JavaScript file before. And it tries to make the old API call with the old structure, makes it to your Drupal site, but your Drupal's cache has been cleared, and the CDN has been cleared, and all of a sudden there's a mismatch. So it's just one more thing to worry about, one more thing to make sure you take care of. I've seen more and less complicated solutions to that problem. Just another thing to be aware of. Now if you're progressively decoupling, it gets much simpler. You sort of have two approaches. One, you can progressively decouple without using an API at all. And two, you can do the standard approach, expose your API endpoints, progressively decouple, like that. Without an API, with and without an API, your app is going to be a JavaScript file, and you'll attach it as a Drupal library as usual. The only real difference between the two approaches, and opportunity for me to use the laser pointer, is this. Without an API, your app is going to read the data from the DOM. With an API, your app will read from the API endpoints. So taking a closer look at the without an API approach, this is the least decoupled option of all. Some people would argue this is not decoupled. But a lot of times when we talk about decoupling, what we're thinking about is using React, or using a JavaScript framework. That's the point. The point is that we get to use this modern framework. So, with this approach, you still create your React app independently. You output your React app as a single JavaScript file. Just follow the latest and greatest documentation from React itself. Typically you'll use something like Babel to transpile your React code into regular JavaScript code, and you'll use something like Webpack to take your many React files and turn them into a single JavaScript file. So your app turns into a single JavaScript file. We know how to load JavaScript in Drupal. We put it in a module, we attach it to a library, and we attach that library to a twig file or use another approach. It depends on if you're attaching it site-wide or not. Now, once this is attached to the page, this is the approach without using an API, right? So you have to make sure that the data that your app needs is available in the DOM. So if you're, for example, replacing a single field, you're progressively decoupling only one field. You don't like that select widget, you want to swap it out with a React app. What you would do is go to that field's twig file and make sure any information that that field needs to pass to the app, it should be available in the DOM somewhere. So in this example, we're talking about a slider and so for this example, we just put a div in the twig file. We make sure to render out the min and max values for that slider. We would, you know, need to use some drupal skills to figure out how to do that, but we would render those from the field itself. And most likely you're overriding the default twig file, so most likely you'll already be able to find those variables in that twig file. In the React app itself, you essentially would crawl the DOM and extract these values. And that would look something like this. At the top, we see the drupal twig file where we attach the React app and we ensure our values are available. But on the bottom, you see the React app and our code essentially traverses the DOM to find which element the app is going to render into. So we might have multiple app sliders, which is why I went with a class instead of an ID. And so here we get all of the elements with a class of app slider. And then we loop through them. For each element with class of app slider, we are going to extract the data min and data max attributes from the markup. We store it in a variable min and a variable max. As is standard in React we call the create root with the element which will act as the destination for the app. And we render our app in that root. So in this example we're using slider, which is a component that we did not create. It actually came from the material UI component library that Amani was showing you earlier. So this really could be almost all of the code. We need to create the slider. So you pass in the min value, you pass in the max value, and that's your progressively decoupled app. You would need to do a little bit more logic to make sure that the value actually gets saved when someone submits the form. But yes, this would let you render the widget in the form. Outside of that it's essentially vanilla JavaScript. So when someone touches a slider on change, let's go update the original form field. So this is the approach without an API. With an API, some things become a little easier, some things become a little harder. You set up the Drupal API endpoints, typically using the JSON API module and JSON API extras. If you're progressively decoupling, chances are you're not going to go through the trouble of creating custom GraphQL endpoints. You're probably just going to use JSON API out of the box. Do your best to only expose the endpoints that you're actually interacting with. It's not fully decoupled, so try to only expose the content type that you are going to be interacting with. Now, with this approach, with the fully, sorry, with the standard progressive decoupling and the API approach, this works better for decoupling a full form, not just one field on the form. So if you wanted to replace an entire form, this is most likely what you want to do. You create the React app, essentially the same as you would any other React app. You make the React app access your API endpoints, and you put a div somewhere on your page as a destination for your app. And that might look something like this. Once again, you attach the library as needed, you put a div as the destination for rendering, and you render it, this time you don't need to pull the information out of the DOM because you're going deeper inside of my app, you're going to make the actual API calls. And assuming this is a form in the form submit button logic, on submit you'll make the API call to JSON API to actually post the form submission. All right. And in a lot of cases, you actually are going to want to place multiple apps on a page. So in a fully decoupled site, you just do one big app that takes over the entire page. But with progressive decoupling, you might think I want to decouple the multi-select widget, and I want to decouple the input with a min and max. I want that to be a slider. So there's a couple of approaches for that. You can either create your multiple React apps as, you know, separate projects, independent projects. You could roll them all up into one, or you can use this feature called React Portals to consolidate them a bit further. And let's compare those three approaches briefly. So we're going to 240, right? Yes. So with the first approach, it's completely independent React apps. So multiple, completely separate apps. You, in Drupal, you also load them as separate apps. This approach is good because it's easiest conceptually. You just work on all your apps separately, load them as needed. The downside to this approach is it's the least performant because all of the dependencies, most of the dependencies are going to be shared, right? All of your React apps need React. But if you build them separately and compile them separately, then every copy of your React app is going to have a copy of React inside of it. So with this approach, you're loading React itself twice on the page. Additionally, the apps cannot communicate with each other, which often is fine, but in some cases, maybe with form elements or other scenarios, you might want them to be aware of one another. Another approach is you can essentially create, once again, separate apps. The only difference is you share the root file, the file where they render from. So you can have all of your logic sort of separate. It's almost like you can have a common root and then one tree for one app, one tree for the other app, but they both render at that top level. And so in this approach, instead of attaching two libraries in Drupal, what you're actually doing is creating two roots in React, essentially finding two divs on your website in React, and you're rendering one app to one div and the other app to the other div. So this all happens in the same file, and because of that, it gets compiled together into just one JavaScript file at the end of the day. And so you only load React once on the page, and it's a bit more performant. But because you're rendering these as separate apps, they, from a React perspective, they are separate apps, they're not able to communicate with one another. A third approach is you truly create a more tightly integrated single app from a, again, common root once again. But this one, the difference is you're not going to call that, you know, render into a root code twice. Instead, you're going to use this functionality called react portals, create portal. And the way this works is within the app itself, you're able to take a subset of the app and render it outside of the app. So imagine the root of your app is your help text region on your Drupal website. And you want an app, you want another app on your page for the newsletter in the footer. And another app for a newsletter in the sidebar, okay? So they have the common root of that help text area. Inside of that react app, you can print out the footer app, or the footer component, and the sidebar component. But instead of just printing them out and having them appear in the help text region, you wrap them in create portal, and you say print out in Drupal's sidebar div, print out in Drupal's footer div. I should have circled the destination. Print out in, you know, Drupal's sidebar and footer divs. And that's inside of the app code. So when the user looks at the website, they'll see their help text app, they'll see the newsletter in the footer, and they'll see the newsletter in the sidebar. They're completely separated from each other. But actually it's all one react app. And they all share JavaScript code, they share state. So you can do cool things, like when somebody submits the newsletter in the footer, they all have access to that variable. And you can say if newsletter submitted, then close the newsletter in the sidebar and put a thank you message in the help text. So you're not fully decoupling, but you kind of have that power to reach across multiple apps on the page, and, you know, have them interact with each other. So this approach is more performant, especially more performant than the first approach. Everything looks like multiple apps, but it really is one app that can communicate to each other. The downside is it's a bit more complicated conceptually. But so with all of these approaches, most of the time approach number two is the one you would use. You render multiple apps into a single JavaScript file just so you're not loading React repeatedly for no benefit, but you're not taking on the added complexity of React portals and sharing state across multiple apps. That generally tends to be the go-to. We will take a quick look at another Drupal project where we used React, and this one we used React. So initially, I'm going to show you two pages. Initially we used just regular Drupal views, and this is for our task management system. So we ran it through the sanitization so client information wouldn't display. But this is our real original task management system. We just kept adding more and more fields over time to create the task, who created the task, who is working on it, and it's prioritized. And what we found was we needed to keep clicking into tasks, so I would need to click this task, I need to edit, I would need to wait for the page loads, change the status, et cetera. And this is something we do a lot. This is integrated to our billing system. But that's why we created React. And so it made us not want to use our task system. So eventually we created a React app. This is the same content. It's really the same, it's like a, you know, same view, but it's not a view. So this is an example of progressive decoupling. We just pulled some widgets out of that material UI. This is internal so, you know, if it was for you see, if I wanted to edit a task, I no longer need to open it in a new tab. I can actually just click here, type right here. If I wanted to change the status, I just do that right here. If I want to change the date, I have these nice calendar widgets from Material UI. They work pretty well. If I want to set the urgency, I have the, you know, the sliders from Material UI. And I have CK Editor or something similar, but once again, that's from Material UI. This is not from Drupal. So this is all just miscellaneous components from a React component library. We just rendered them and popped the information into them from the API. Very little CSS work, which I'm sure you can tell, but it still looks and works pretty well. Really the UX is much easier. It's so much easier for me to in-mass close out tasks, send out invoices. Even this little pop-up thing, that's another component. They have a component called something like snack bar, and you can configure it. Pop-up bottom left, bottom right. These are all just attributes on the components. If I want to track progress, they have a modal component. So it pops up in the presentation. Drupal. Write how long you worked on it and submit. And when I press submit, the JavaScript code makes an API call. It has a link to view the full task, which takes us out of React land back over here. And you can compare, just as a quick example, those date widgets in Drupal, just depending on the field type that you clicked, it's showing the time, which I don't really care about the time, I care about the date, and it's a hassle to remove the time or to change the field type. But with my React app, I can just pick the component that shows the time and I can set the attribute, or I should say that shows the date, and I can set the attribute to hide the time, and it just works. Whereas with Drupal, maybe I have to do that. Yeah. So that's an example of how we're benefiting from this progressively decoupled setup. We've got this refresh all apps. It's all just more intuitive, more app-like better UX. And we really like Drupal. I like Drupal's theming layer a lot. But on this site, this is the one place that we spend a lot of time here. It would be great if we didn't have to refresh the page so many times. All right. That's pretty much it in terms of this progressively decoupled material. We're a training company. If any of you are developers, but we have a number of courses including ones that teach you how to become an architect. So if you're mid-level senior, the architect series is five three-hour classes which teach you how to make your Drupal site more performant, teach you how to architect your front end, how to write automated tests, how to write maintainable, refactorable, object-oriented code, and how to structure your data. We've got other courses like their certification exams. We can help you do that. PHP object-oriented programming with symphony and a one-day advanced module development course. We also have some React classes to essentially finish some of these examples I was showing you where we showed you how to crawl the DOM to pull information from a field. We have some training classes where you do a project. We also have some training classes where you do a batch and you replace some widgets and your form works and you don't have to even pull out an API to do it. And we also have some examples with using an API. So I hope this was beneficial. I hope you enjoyed it. If you have any questions, we're open to it. So the first one. How does Google feel about decoupling? Well, Drupal, the application is fine with it. It's no downside, especially if you're progressively decoupling. Progressively decoupling is really just adding JavaScript to your site. Drupal has always played nicely with JavaScript in terms of being able to embed it on the site. The Drupal community is strongly in favor of decoupling. You'll see a lot of talks about it. Drupal Pitchburg, they did fundraising and multiple decoupling projects, I believe, were selected. So I think it's just going to keep getting better and better. Drupal's JSON API implementation. JSON API is a spec that is created outside of the Drupal community. I don't know if it's still the case, but at least at some point, Drupal was the single most thorough implementation of the JSON API spec that we are aware of. So Drupal is actually very strong in that regard. How much custom code would you need to do something like progressively decoupling? Not too much, because, again, there's component libraries out there. So if you think about Drupal, I feel like back in Drupal 7, there used to be the iPhone, there's an app for that slogan. I feel like in Drupal 7 we used to say there's a module for that. And in React it feels like that. There's a component for that. There's a component library for that. So whatever it is you're trying to do, there's something that looks good. Drupal is more focused on functionality in a lot of ways. But React is really focused on UX and design. So imagine a whole community just focused on design and UX and you're allowed to use their components. That's really what we have. So you can just use them and you can plug them in through your APIs. Can this be put into a module, like a contrib module? It could. And I think in maybe Drupal 10 or Drupal 11, I know they're working. I think it's my cursor. He talks about it quite a bit. But there's a movement towards making front-end components part of Drupal core where you can do things like JavaScript. And I haven't heard of it discussed in this context, but I think that lends itself really nicely to bringing in React components, mapping the properties in the YAML files and possibly being able to say, hey, here's a component that needs these three properties. Here's a field that has those three properties. Let me just through the UI configure it. So I think, you know, with time hopefully we can get there. Any other questions? I've been sharing multiple times. It's a good question because we're talking about attaching JavaScript files directly, not using Drupal behaviors in these examples. But with that said, I mean, you might only need to worry about that if your React app is nested inside of something that's using Ajax. Yeah, I think it's unlikely. React itself is also pretty good about deduping. It has this whole virtual DOM concept. We've never faced that issue on our site. We've been using our app for years. And that's just never come up. And I think if you just attach it through the library, I would hope that Drupal would, you know, treat it like a regular behavior. In my experience, yes, but I would avoid making React appear and disappear. I think React appearing is fine, but making the whole app disappear and reappear, I would imagine that it wouldn't maintain the state after disappearing and reappearing, but if it were done, yeah. Yeah, it shouldn't have an issue, especially because, you know, we bring in other JavaScripts all the time, like Google Analytics, et cetera, but it's not firing multiple times. So, yeah, I've never seen an issue with that. Oh, sorry. I should look to the right. I've got the wrap it up sign. All right, well, thank you. I hope that this was beneficial. We're at the Debug Academy booth if you'd like to say hello or talk further.