Talking Drupal #353 - Native Web Components

• What are native web components
• How are they different from custom elements
• How are they different from JS frameworks
• Libraries
  • Elix
  • Bit
  • Polymer
  • Lit
• ShadowDOM
• Difference between Progressive Web App and NWC
• Benefits of NWC
• How do you use them
• What are lifecycle callbacks
• Styles
• Html
• Slots
  • named
  • anonymous
• Support for NWCs
• Use cases
• Anything else?

Transcript are generated with AI and lightly edited, therefore will not be 100% accurate.

John P  
This is talking Drupal weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 353 Web Components. welcome to Talking Drupal. Today we're talking about web components with Ron Northcutt. Ron has also been involved with Drupal for a long time since 4.6, and an Aquarian for over seven years. Ron is a jack of all trades, and currently working as the Director of Technical Marketing at Acquia. You can hear Ron previously on episode 342. Ron, Welcome to the Welcome back to the show. And thank you for joining us.

Ron N  
Thanks. Awesome to be here. Appreciate it.

John P  
I'm John Picozzi. And today my co hosts are joining us for the second time, Donna Bungard, Senior Accessibility Program Manager for marketing at Indeed, Donna, how are you?

Donna B  
I'm doing great. Thanks for having me back guys.

John P  
And Nick Laflin. How are you, sir?

Nic L  
Very good. I'm super excited about this show. This is the most front end, I feel like this is where front end and back end really meet more than usual. So I'm super excited to talk about web components.

John P  
I am going to throw up the rabbit hole alert. When Nick gets really excited about the show we tend to go down some rabbit holes. So brace your brace yourselves, listeners. All right, let's jump into the module the week which I'm like, absolutely shocked that we have not done this one. Because I think we've all used it from like, Well, Ron may have used it as early as Drupal four, six, according to his intro, but I think we've all used it in Drupal seven module of the week, this week is menu block. So I'll let everybody chime in on this module. But basically, it does exactly what the title of the module says that it does. It allows you to select a menu and then allows you to create a block from that menu really helpful. I find or have I found, I guess I should say, in like creating sub navs or secondary navigations on pages because you have the ability to select like the parent item and then either show or hide that parent item and display it in a block. So yeah, can be super helpful.

Nic L  
Yeah, that's kind of the primary use case. Because you know, in core Drupal nine, Drupal eight, you can add a block a menu to a block on page. But you can't specify parent only or starting at the third level. This this module really is key when you have kind of a deep nap needed to have contextual menus, it just makes it really easy to kind of in configuration, make those changes and just drop it on the page somewhere.

Donna B  
Well, I was just gonna say way back when I was still doing the the front end Dev, I'd use it for a real quick gateway into creating a landing page because I could exclude the menu from it, and just add whatever I wanted there really quickly. So if I was tight for time, that that was my, it was my first love for that.

John P  
Ron, what do you want to add?

Ron N  
I was just gonna say there was a specific site, I remember using it for back in Drupal seven, it was the Marfan Foundation. It's a nonprofit for people to suffer from Marfan Syndrome. But the thing that we use it for is we had a very complex navigation structure with a lot of like, I think it went down, like four in some places, maybe even five levels. And so what we're able to do is by keeping the top level nav, without any dropdowns, we were able to once you jumped into a section that whole subsection with, you know, path alias, was able to show that piece of the menu nav down there. So we were using a single menu for like the entire thing. But once you get into a section as we talked about earlier, it was a perfect clean solution. I was very pleased.

John P  
So now we have done many block and we can add it to the to the rolls of history. Let's jump into our primary topic. We want to make sure we have plenty of time for Nick to ask all of his burning burning questions. But I'm kind of new to this topic. So I'm going to ask the really super basic question to start off Ron, what are native web components?

Ron N  
So I in in the browser spec there are a few kinds of API's platform API's that you have available. And there are a few key ones that you can kind of use together to give you this functionality of like a web component. So a lot of people may think of a component is something like belonging to React or Angular or things like that. But the beautiful thing about this is that you don't actually need that external framework. So there's custom elements, which we can talk about a little bit, the Shadow DOM, which is kind of like an encapsulation of your your styles and things, the ability to add modules in JavaScript, yes, and then templates and slots. And you can use some or all of those things to a certain degree to create web components. And the really fun thing is, at the end of the day, you've got that web components, and you can reuse it over and over again. And using some of these different strategies, you can make them configurable, programmable, very, very cool, powerful, fun, little things.

Donna B  
So go a little deeper with me, tell us how web components differ from, say custom elements?

Ron N  
Sure, yeah. So I actually started working with custom elements, and they can actually take you pretty far. So for folks who may not know, in HTML, of course, you have elements like a paragraph or an anchor, or, you know, unordered list or something like that. So the with the custom elements spec allows you to do is to create your own elements that do not actually exist. So you could create a talking Drupal element. And you might say, I have a talking Drupal elements. And it has an attribute of episode. And so if I do talking Drupal episode, hosts today, 353 333 53, then your custom element could then render, like a little player or something with that specific episode. That that's so you can make all your own things. But the other cool thing about custom elements is you can extend regular elements. So I could make like a to extend a paragraph element. So I can make a talking Drupal paragraph elements that does something specific. So when I put in my text, it might do something else, or my filter would have you a Web Components kind of bigger than that, because you'll take that custom element that you have. And the web component, excuse me, the the web component allows you to use other API's to kind of extend it out whether you're going to use the Shadow DOM to kind of create more like a lock down almost like a micro front end. You can use the modules to kind of pull in different things or use things in different ways. Or then obviously, the templates and slots where you're going to really kind of make it more more like a widget, if you will. So anything Anything to add, Nick?

Nic L  
Yeah, I mean, I would say one of the primary pieces of native web components, as I've seen them use is that custom element piece, you're basically encapsulating your styles in your functionality into a custom container. So you can add whatever attributes you want, you can add whatever properties you want. And while it does require JavaScript, because it is, you know, based in JavaScript, it is native to all browsers at this point. So it's basically just HTML and JavaScript, you're not. So you're getting a lot of the flexibility and custom functionality that you can get with these frameworks. Without all the overhead of those frameworks. You know, react can be, you know, or Angular can be megabytes and megabytes of JavaScript that you have to download. And it contains the whole routing system. It contains a lot of a lot of stuff. Whereas a native web component can literally be you know, the example that you almost always see when you're looking for tutorials and things are, you know, like a counter or timer, you know, that kind of thing. So you can have interactive. You have interactive functionality that isn't kind of the way that you normally work with JavaScript, where it's like, find something on the page, do something with it, and kind of mash it to how you want like you're in a self contained bubble, essentially, within that component.

John P  
So I've, I've, I've done guy questions. So an element element is really just like you like an HTML tag, basically like a p tag input input tag button, whatever. custom element is just like JavaScript that either builds its own element or modifies an existing element.

Ron N  
Yeah, basically. Okay, you could, if I'm going to I'm going to make an analogy. I haven't thought up until now, but maybe this will be good. May this be horrible?

John P  
I love first time analogies go.

Ron N  
Okay, excellent. So if you think about Drupal, and Drupal core modules, then you could sort of make that analogy to HTML with kind of the default tags, elements that come like the p tag, the input the button. And then I have my contrib, and custom modules that are layer on top that add additional functionality that didn't exist before. So a custom element would be kinda like that, like, the browser doesn't know about it. So it has to load the JavaScript, which defines this element that makes it available on the page. And then when it sees talking Drupal, it's like, Oh, I know what that is. I know how to render

John P  
that. So it it in Sorry, I'm going down a rabbit hole here. But I'm trying to get a better better understanding. So it takes that custom JavaScript, and the browser has an API that says, Okay, this is a custom, you know, a custom element. And I'm going to use that. So then it uses that to interpret the HTML when you write your HTML code, like, oh, when, you know, if it were like HTML five, and you had like a video or an audio player, right, it would load that same deal with like, our talking Drupal custom element. Right? Right. Yeah. So then bringing that back up to the web components, web component is really just a combination of custom elements and elements into like a component that you can use

Ron N  
to do whatever kind of crazy stuff you want to do. Right?

Nic L  
Yeah. And as, as an example, my, my website actually uses native web components. And I have one for TD episodes. So there, there's a, an Element, enlightened dash TD dash episodes. And what it does is it takes the feed from YouTube and takes the most recent episode and just displays it on the page. So you can you can use it to even do kind of simple things like that. But the nice thing is, is it's it's encapsulated, you know, the functionality is there, you can also work with, you know, some component libraries to kind of test things and make sure things stay the same. And then when you're deploying them on your site, they're they're encapsulated, you know, you can be fairly confident that they're not going to change.

Ron N  
Well, and I liked, you know, when you mentioned about html5, right, and so you think about something like the picture element, or video or whatever, and you've got this great native functionality that didn't exist before. That's a standardization and industry standard. But that same thing applies to what we're talking about here. So if I want to come up with my own thing, like, for example, I started using these a lot with the with commerce commerce framework, which is kind of a reference architecture that we created. That's where I started going down that particular rabbit hole, because I was trying to create something that was reusable. So I could reuse it across a whole bunch of different things. It was following some some common standards and patterns. And I wanted to build a library. But I didn't want to have a dependency on a specific framework. I didn't want to force people to use React or Angular. So that's how I ended up there. And then just the fact that it's natively supported, I'm a huge believer of trying to use what comes out of the box as much as you can keep things simple. So

Nic L  
yeah, I mean, and that's one of the reasons why the projects that I've talked about over the last few months is using one of their requirements was were, you know, my client was hired to build a design system. And their client has 1000s of websites across 10, or 15, different platforms, Drupal, SilverStripe, Wordpress, Dreamweaver, like little HTML sites. And the design system needs to be able to be integrated with all of those without a huge lift from their development team. And, you know, that's one of the only ways that you can, you can do that as native web components. Otherwise, every every development team is gonna have to take, you know, a typical design library says like, here's some example HTML, here's some example styles. And then each development team has to then take that find out how to fit that in their template, find out how to write the styles in a way that doesn't override other styles that they have on their site. And with native web components, really, they just have to, you know, the integration point is get this JavaScript on the page and wrap your content in this HTML template. And as you do that, it will render there's some caveats. If you do that, in general, it will render exactly the way that it looks in the design library. There are some exceptions that we'll probably get to. So I do have another question for you, Ron. Because you know, as I'm, you know, this, to be honest, this project that I've been working on is one of the first projects where I've used network components extensively. I, you know, I've used them in past, but it's always been either in conjunction with some library, some framework, like React, or it's been kind of just proof of concept stuff, like, you know, how do you create a custom element type thing? You know, and as I'm building this, I've been looking at some libraries. And I'm curious if you have used any of the top libraries they find people mentioning like elix, or bit polymer, or lit HTML, are those are those native web component libraries that you've, you've looked into? Are there others you'd recommend?

Ron N  
I've played with Lit seems to be pretty popular, I have not used the others. I think the key there is just to make sure that you've got something that's that you can kind of standardize on because they've all kind of got their pluses and minuses. There is another tangentially related library that I haven't had chance to play with. But I'm very intrigued by and it's, it's called Mitosis. And it's from a company called builder.io. And it's tangential because what this does is allows you to create your components kind of in their mitosis framework, but then you can output that to it'll and it will, it will render it as a React component or as a lit component or as an angular or as a native or as a svelte or as whatever it is, it is it's a really clever idea. I don't know how useful it is. But that is also something kind of fun to think about.

Nic L  
I have to look into that because i I'll be honest, I just discovered a Bit yesterday, actually. And one of the reasons why I started looking into it was because it seems to have similar functionality. I dropped it because the install like I, you know, I started the install process, and it's like multiple gigabytes. And I'm like, why is this NPM project to build native web components, multiple gigabytes? It seems a little absurd, but I think a lot of it is tooling for for building that. But, but I will say I have used Elix. And it tends to be a little bit bigger than doing something natively yourself. But it's also somewhat plug and play. So for example, I was looking to, I spent probably a couple of weeks on a personal project, trying to build a carousel as a native web component and kept running into weird, weird behaviors or edge cases. And so I was like, Okay, let me just try using Elix has a lot of carousel. So I'm like, let me try Elix, it took me five minutes to write in write custom made Web Components myself, that just kind of built on top of Elix. And it just kind of kind of works. Now, like I said, it's a lot bigger, you know, building, building a carousel on the other project, you know it using like a glide library or something added maybe five KB of race using the Elix, one on that personal project added 250 KB or 200 KB. So it's significantly larger. But again, it's a Elix is a, an extremely large open source library of components. So if you're if you're even just thinking about doing web components and wanting to see like, hey, what kinds of things can be done. Elix is a great resources just just to look at, like if you want to see like calendar pop ups or timers or carousels, it gives you a really broad range of a really broad range of projects that you can do in native web components.

Donna B  
I'm thinking of these libraries, I'm thinking of the accessibility of them. And if there's one that can be verified that are, you know, I, as an accessibility professional, I'm always going to, you know, hold my breath a little bit with carousels. But in general, though, with these components, if there's ones that are already, maybe not only compliant, but are really considering the user experience that isn't necessarily considered with under the WCAG guidelines. There may be some fantastic opportunities there to to bake accessibility into what's going on just by utilizing the work and streamlining what you're doing. It's a strategic win all around.

Nic L  
I I'd say actually I'd love to pick your brain. I don't think this episode is necessarily the place to do this in detail but on this project I'd love to pick your brain on it because and I'd love your opinion on this Ron too but at a high level, at a high level, you can make these accessible because they're just standard, a standard HTML, even though it's your customization, well, you can do that. But we have run into a few edge cases, I think due to the I suspect is through the Shadow DOM where it doesn't quite detect. Things are on top of each other. So it can't detect contrast properly. But in general, because it's just natively supported functionality, accessibility is very achievable. Whereas a lot of these JavaScript library frameworks add so much stuff on top of it, that it's a huge barrier to make them accessible. That being said, it does use JavaScript. So non Java sprite prop are a major caveat.

Donna B  
Well, in general, though, there's also things to it sounds to me like when you're talking about the native HTML versus the other things, we're talking a lot about assistive technologies and screen readers, which first of all hugely important, visual barriers can be profound. That is only about 2% of the population of the 26%, that identify as disabled. So we really need to think in terms of, you know, motion impacts, ADHD, vestibular issues, some people identified in the spectrum, some people who have just or maybe English as their second language or low literacy, that speed individuals who live with anxiety, things like that, there's a lot of other reasons that we need to consider beyond just that screen reader compatibility, but it's a fantastic first step into a larger strategy for sure.

Ron N  
You can you can also one of the strategies that I like to look for, to kind of help with some of these things is progressive enhancement. So like, for example, if we had what we talked about earlier, the, the the talking Drupal element, until the JavaScript loads to tell the browser what to do with that element, it's basically going to be ignored. So if you're not running JavaScript, or if you got a slow connection, or some other problem, it might be problematic. So one thing I try and look for ways to do progressive enhancement, where I can add, typically by extending an element, so I'll give you a specific example. We recently rebuilt the developer portal at Acquia. So dev.aqua.com. And on all of the pages there on the side of the page, there's little blurb at the top about the author. And it takes the the summary description of the author's profile page, and it displays it under a picture. But we're also making a sticky on the side. And so that's too big. So what we wanted to do was have that be basically collapsed down. So you see like the first two lines, and then there's a bit of a fade with read more, so you can open and close it. Now the original plan was we were just going to build that just we tried using a library for that module. And it worked, okay, but it didn't do what I wanted it a little too clunky. So we're going to make a custom web element, nice and simple. So we made the custom web element, but we extended the paragraph tag. So in the HTML in the markup, it's p, and then is equals, I think it was fade, read more. And so what that told the browser was, hey, look for this, this is a custom element called Fade readmore. But it's an app that extends the p tag. So when the page loads, and if you don't load any JavaScript with the JavaScript is slow, the paragraph tag is still going to be rendered as normal. It's just going to be a normal p tag. But then once the JavaScript is loaded, once the browser sees it, it will then re instantiate and then it does the little fade, and it drops it down again. And so there's some things you can do with that kind. Yeah,

Nic L  
I would, you know, actually, I can, I can see some applications for that, for sure. So I'm actually have to look into like most of the web components that we do have to be like custom. But I wonder if we can convert a couple of them to be just extensions.

Ron N  
I'm a, I'm a, I'm a big fan of that approach that progressive enhancement, because you can do you can also do some things like for example, you could, that particular component, we also extended so you can program it with attributes that tell you how tall it should be, and what the label should be if it's read more or expand me or whatever it is. So it has defaults, you can program it so you can reuse it. But you could do things straight out of the box, for example, so that visually you're only showing and you're clipping it. Yes. So the text is all there. So screen reader can still access it visually. It's kind of what you want. It doesn't have all the functionality you want until JavaScript runs. But that's that kind of idea of progressive enhancement. Let's, let's try and provide it a solid foundation that works for everybody. And then let's add additional stuff on top. To make sure we can kind of give a more app like experience.

Donna B  
The only warning, I'd say, with something like that is to keep in mind that some screenreader users are visual users. So if somebody is looking at your screen and having it read text that they haven't clicked on, that might be a confusing user experience. So that's just something to keep in mind. It typically, screen readers that are designed for different disabilities may or may not interpret it the same way. But it's something just to think about when you're going through it.

Ron N  
Would that be would that be a place where you use something like an aria something, something to kind of let it know that it was collapsed? Or it was, you know, I'm talking about

Donna B  
an ARIA label might sorry, an aria band or something might be I'd have to work through this? Yeah, not the time, we could go down an entirely. I actually just jump in real quick and ask a question. I keep hearing the phrase Shadow DOM, and I've been out of this a while the developer side, what is that?

Ron N  
Sure, sure. So Shadow DOM is you can you can almost kind of think of it like an iframe. It's not an iframe, it's not loading an external site. But basically, it's like, you have this little box, and the box is inside the page, and you have your DOM inside there. But it can also have its own styles. So the simplest way to say it is if I've got styles on my page, that turn all of my paragraphs to purple. Anything inside the Shadow DOM is not going to be purple, the P tags will be purple unless I add the CSS there. So it's a way to kind of separate so that separate the styling, and what's going on inside that box. And kind of encapsulated away. That's why like, Nick was saying you can do things like, sometimes it can be really difficult. Let's say you put a button or something on and you want it to look a certain way or do a certain thing, and then you put it on one page, and it breaks because the styles are doing something weird with a specific button, you're like, Man, that's I didn't intend for that to happen. Now I gotta go and undo this thing or do it not or so this allows you to kind of like really kind of dial in, inside the component, if I'm using the Shadow DOM, but you don't have to, yeah, anything inside that is going to be encapsulated

Nic L  
in and it encapsulates both ways. So if you're using the Shadow DOM, whatever site, it's on, the parent styles won't leak into your native web component, right? And the styles in your shadow DOM won't be to the parent website. So it's both ways. So this

Donna B  
is a way to encapsulate it, it actually doesn't impact the DOM or the reading order. So again, I am to give that screen or to technology or those reader technologies that read the DOM and not the visuals. So it's, it's an encapsulation, it's basically putting up little puppy fences everywhere instead of actually rerouting somebody, okay,

Nic L  
there. There are two exceptions to that. One. And this is starting, we're moving ahead a little bit, which is fine. But there are two exceptions. One is slots. Slots technically are physically in a different location. But they're in their reference from the Shadow DOM, we will get to what slots are in a bit. But I think the way that they're speced they treat, they're treated as if they're in that order. So functionally, they're in a different location. But for sooner, they're not. And then the second thing that the other exception is there are three things that do pierce what's called pierce the Shadow DOM. So fonts that are in the parent are accessible to the Shadow DOM. Custom CSS elements, what most people call CSS variables that are set on the parent on the parent website are accessible to the Shadow DOM. And I can never remember the third thing because you know, it's never used. But there is one other thing that will pierce the Shadow DOM. And Ron, I don't know if you remember off the top of your head.

Donna B  
I've gotta tell you.

John P  
Is that encapsulation, like a security metric to like his information from one to the other, not shared, like if you had, I don't know, stats or numbers or some sort of information in your web component. You In the shadow DOM.

Nic L  
Yeah, so for example, by dt, so So for example, it is, ultimately the information is on the page. So if you really want to, you can use JavaScript to get that information in there and affect it. So I mean, it is HTML. So you can get in there if you really, really want to do non standard things with JavaScript. So that's one caveat. But in general, for example, if you have, if you have a menu that uses the Shadow DOM, for example, by default, Google isn't going to see you clicking on those items. Now Google would see that you got to the destination page. But if you have analytics on the page, it's not going to see that click event, unless you do some, some work to expose that event to Google. But if you use slots, and the menu is actually in the light DOM, then Google natively is gonna see all those click events the way that it normally would. So there are some considerations when you're looking at other things interacting with your, with your native web components that are there are things to consider.

John P  
So I have another, I don't know, maybe it's not a dumb guy. But I think it might be dumb guy question, because we're gonna, we're gonna mix two, we're gonna mix two, two things and see what happens. So we were talking about native web components. And I'm wondering how they differ from progressive web apps. And I mean, I know what each of those things are now. Thanks. Thanks to you, Ron. But what? Can you use a native web component in a progressive web app? You know? So first question, how do they differ? Second question, Can Can Progressive Web Apps contain native web components?

Ron N  
Sure. So just to set the stage, for folks who may not be aware, or heard PWA, a progressive web app, basically, that's, that's a process where you're just gonna be taking the standard stuff, JavaScript, HTML, CSS, and you're kind of starting to use some functionality that's built into browsers now to lie to get what we might consider more native app type of functionality. So simple things like the ability to work offline, to preload things into the cache locally, to be able to, you know, if you've ever seen an app, like Spotify, or I think I don't know, if Twitter still does, where you can like save to desktop, or save to your homescreen those kinds of things, they use a JavaScript workers in the background. So that's kind of what a PWA is. And then if you're going to be using a native web component, you can use it just like any other element, it's just HTML and JavaScript at the end of the day, so there's no incompatibility. And however, I would say that there are some very interesting possibilities when you start to blend the two things together. So for example, as I mentioned, you've got and there's a great module in Drupal, maybe it should be a module, the week at some point, the PWA module, which is lovely, because it's simple. And you just turn it on, it just works. And you can extend it. And it allows you to do the same thing where you can kind of, you know, save this as an app. So like, I've done that on my on my phone, I've got a couple of sites using PWA's, and it's just a, the icon on my on my phone, I push it and it opens it up. And it's it's a browser, but it's there's no chrome around, so it looks like an app. But the cool thing about that is that you can do things like it's caching a lot of the data. So if I turn off my connection, going to airplane mode, I can still go browse through the site, and do things and potentially interact with the site and have it catch up later when it makes a connection. Now, that's kind of the Holy Grail. But the reason I mentioned that is because there's some really interesting ideas about things that you can do. If you were going to be creating some of your own web components, or using some out there that interact with those workers. So for example, to do a forum like to leave a comment that was going to kind of only live on my local while I'm offline, and then catch up and post to the site later. Once I have a connection, that might be much easier to do as a components, because I can just do it in one place, and then reuse that over and over and over again, for all types of things. So that could be interesting. Or like we talked about earlier, you could extend the form element to be like an offline form. I don't know if I'm sure someone's done that. That will just follow certain standards and have whatever limitations but then you could use it for different things for like liking or following or commenting whatever.

John P  
Do you know of a native web component library for progressive web app?  because it sounds like you could very easily create native web components that you could use in a progressive web app or uses the kind of the service back end to,

Ron N  
I don't know, off the top of my head. But my goodness, wouldn't that be a cool thing? To have something that was like, make a module that dependent on the PWA module and provided, you know, an integration for flag or comments for all of those fun things

John P  
that you create that I'll take? I'll take one creation credit, there are half of creation credit,

Ron N  
a credit. Inspired by, there you go. Yes. Okay, cool.

Donna B  
So what is the benefit of these native web components overseas, some framework specific ones, and I'm thinking where we're talking about a potential library, I'm with this, I'm gonna get my answers along those lines. But I want to hear your thoughts, your words?

Ron N  
Well, my opinion, right or wrong, because there's, they're not perfect, you know, there's pluses and minuses. But my opinion is that I prefer keeping things simple. So the fact that I don't necessarily need a framework means that there's less weight to the page, there's less complexity. That's a big one, it's one of the reasons why I'm kind of a fan of frameworks like Svelte or Solid, that render out to native JavaScript. Because you, what you end up with is what I'm kind of going for. The other cool thing is that you can use them and reuse them, regardless of framework. So if we created the talking Drupal Web Components today, then you could use it in a React app, you could use it in an Angular, you could use it in Vue js, you know, over and over again. And there's no real major problems. And then the I think we're gonna see more of this kind of, as we see more of the expansion of the native browser functionality, like I'm really interested in, oh, goodness, the assembly WebAssembly, I saw a thing it's called. That's something basically lets you run no JS with an IDE in your browser as a native web component. So these are like groundbreaking kinds of things. But web components used to be groundbreaking, now they are standard. So the idea of kind of building on what's already built into the common framework. It's just a pattern that I prefer. But

Nic L  
so when you're looking at requirements or building something, what kind of makes you think this is a good use case for web components? Because like you said, there's some limitations, there are some things like for example, I generally wouldn't recommend using a native web component for like full page layout stuff. I think that I mean, you could but I'm usually I usually wouldn't consider using it for like full page layout, like is there a sidebars and not a sidebar, you know, where that kind of stuff goes, it's a little bit more granular than that. What kinds of what kinds of things tell you like, Hey, this is this would be a perfect, perfect for web components. And this kind of excludes it from, you know, being a web component.

Ron N  
So I, I did a report with a ORiley a little while ago on, it's not very long, but it was on this this concept of creating the virtuous cycle in your projects. And I kind of came up with this, thinking about resources. And there's kind of like this inverse relationship. So for the developer, developer time, is the most valuable thing. For the end user, the developer time is honestly kind of meaningless. They don't care how long it took you to get there. They just want what they want. On the other side of the spectrum, you've got, like how long it takes to download and process and deliver the page, which for the end user is critically important, right? And they want it to be as small of a payload as possible as low loading time as possible, like near instant. Technically, even though that's not really how we think. But objectively for the developer, the developer doesn't necessarily have to care about that. It's like, Hey, I delivered you the functionality. And you've gotten you can do whatever. So I like to think about it from both sides. So from the user perspective, I want to keep going to keep the payload as small as possible. So I want to keep JavaScript as small as possible. I don't want to use frameworks unless I have to, I want to rely on native stuff as much as I can. I want to keep CSS small etc, etc. And the when you start adding native web components now you're adding to the potential weight of the page, the trade off there is that if you need or want that type of functionality, it can be a heck of a lot more efficient than something like React, as we pointed out. On the other side, though, from the developer experience, one of the things that these components can do, especially on the front end is they can encapsulate a lot of that reusable functionality and make it much faster and much easier to do things. So there's always going to be a trade off. So for me, when I think about it, I tend to think, more from like the atomic level up. So thinking about the specific atoms that compose a page, and then the specific components that compose a page, and looking at places where is there functionality that if I encapsulate or if I'm going to use a micro front end, like with a Shadow DOM, that that's going to provide value to the end user who's receiving it, that's going to be more points in favor of, and then what does that mean for the developer experience? Is that going to increase it is that going to make us faster as I can enable us to focus on doing work on one thing that use 10,000 times? Well, heck, then that's gonna give me a lot of value, which means I can roll things out fast for my users. So that's, that's kind of where I start looking. And then once I start getting into the page, it's typically around things like more advanced interactions, more app like functionality. That's where you start to ask those questions like, Hey, does it make sense to do this here? Other than there's also the question of, do we need that app like functionality? Do we really? Do we really need that carousel? But you know, then you get there

John P  
So? So what are lifecycle callbacks? And how would one use them?

Ron N  
Very good question. So as we mentioned, kind of earlier, the, you know, when you have a web component is the browser doesn't know it exists at first, right? The browser is loading the page, it knows what the default HTML spec is, but it knows it doesn't know about this custom stuff that you kind of use these hooks to put in place. So but it because of the API, it has this avail ability to discover, and then render them. But then sometimes they change, right? Like, if you have a counter and it's the counter is going up, you want to potentially know when that happens, you know, events, or sometimes things go away. So there's, there's a lifecycle that's associated with the components who it's kind of like hooks in Drupal, right. So you know, when something is created, you know, when something's updated, you know, when something's destroyed, and you can use those to kind of listen for things or inject certain things or issue, you know, events to let other components know something happened, so they can be listening, etc. I did find one, I don't remember off the top my head, it was in that commerce reference I mentioned. But there was something very specific that was really driving me nuts with this component I was trying to do, because it was trying to build the component. And it was looking to register, I think it was a callback or something. But that library hadn't been loaded yet. And so sometimes it worked. Sometimes it didn't. So I use the lifecycle function. And so basically, I waited until everything was loaded. And this was completely fully loaded. And then, in that part of the cycle, I was able to add the piece I wanted. So

Nic L  
it's important to note, for example, some of them are really like, not all of them are really important. But for example, when you create a native web component, you can determine what attributes are on there, like an attribute B, what color is it or something like that attributes aren't available in the constructor method, when you're creating it attributes are only available at the after the what's called the connected callback. So you need to kind of know where where to do things. Speaking of which, that's one of the actually, I'm curious if you know how this happens actually Ron. storybook does something that breaks the lifecycle callbacks, or maybe it doesn't break, maybe smooth the lifecycle callbacks. In native web components, for example, like I said, attributes just are not available to a native web component until the connected callback. But if you haven't a web component in storybook, and you do something with an attribute in the constructor, it'll work. But then as soon as you try to integrate that in a real site, your component workouts and yeah, because the attributes aren't available at that point. I'm just curious, do you know what sortybook I've not been? We'll find out what the heck storybook is doing to do that, but I assume with some react, Matt Check on the back end, and that just forces them to reload. But

Ron N  
that way that wouldn't be my, that would be my guess. Because we, the, there is a module that I like to use called the component singular component module. And it allows you to add web components into Drupal. And they can be rendered as libraries or as blocks. The reason I mentioned this is because if you add a form, which is just in the YAML, was passed up to the block, you can configure what the attributes should be. But because Drupal doesn't know about the web component, the attributes are passed through as a wrapper around the web component. So you have to like go to the parent to get them if you want to pull them in. But I can go to the parents and get them in the constructor, because they're already out, put on the page. Yeah, so I'm wondering if versus the Shadow DOM, and we're not piercing the Shadow DOM and invoking the Necronomicon, or whatever. So I'm wondering if maybe storybook is doing something kind of like that, like, it's, it already knows that those things are there. So it's kind of keeping it there for like, fast reloading and what have you, but just a guess I haven't really used storybook much,

Nic L  
I assume. So one of the things that also kind of trips up new users, or new web component builders is styles. Where do your styles go when you're creating a native web component.

Ron N  
So I'm probably a little bit different, because I'm not a native, you know, front end person, or back end person that's learned some front end stuff. So as we talked about, you can use the Shadow DOM, and you can include styles that are just encapsulated there. Personally, I try to avoid doing that, unless I really need to, like I want my components to be as generic and vanilla as possible, and play nicely with wherever they live, because I'm gonna be able to reuse them and put them in. But But yeah, that's where you have the choice, right? You can, you can either do it inside the Shadow DOM, where it's going to be encapsulated. And part of it, which totally makes sense if for things like positioning, or if you have specific things that are maybe not necessarily so much about styles, like colors, maybe, but more about, like, how things are displayed, or how things were or that there's a display, not until you click on something, those types of things, you definitely would want to encapsulate that you don't want it to affect other things. But otherwise, I try and I try and be as friendly as I can with whatever the parent pages and just allow that to cascade.

John P  
So I got I got kind of like a, an overall question here. Because I, I'm, I'm getting it as you guys are talking, which is awesome. But I'm also trying to figure out, like, you know, Nick's question of like, where did the styles go? Right? And, you know, my, my question of like, Where does the HTML go? I guess I'm trying to figure out like, there's two parts to this, right, like my component and the JavaScript and the HTML that kind of like, run my component, right? And then there's like my page that I'm building. And I'm wondering, like, how you kind of wire that all? Like, where? Where does the native web component live in reference to like, your page and a page that might be calling it right? So is it something like, for example, will will, because this is a Drupal podcast will bring everything comes back to Drupal? But, you know, is it something where there's a certain folder structure in your web routes that like a browser just kind of understands and says, Hey, there's a, there's a modules contrib folder, and it has a, you know, you know, native web component, component folder that I can pull all these components in from? Or is it something that you're just basically calling it at the top of your, your page, as you know, as a call out to JavaScript, and then the browser's kind of interpreting that and doing its thing?

Ron N  
Yeah, I mean, it's, how do you choose to organize and load the files onto the page? Yeah, I mean, I can, again, my opinion, the way I like to do it, because I started with Drupal, and I've kind of backed into the front end, is I use that the component module was specifically created for this purpose, because it hooks into Drupal. And those JavaScript files, the CSS files and things that I needed are added as libraries and dribble for each of my components in the Yamo, I define whatever dependencies there are. So I can Drupal will take care of loading my dependencies, it will take care of aggregation, getting the stuff on the page where I want it. And at that point, I try to, I think about it like you, you can create one off components. And you can go to like web components.org, for example. And there's tons and tons of them, and there's some for lit and bid and all those other ones, you can grab them. And that's great. But I tend to think of it in terms of like, like a package, like a library of components that hopefully have some shared dependencies that hopefully have, you know, know how to work together and interact together. And that's where your functionality comes from. And that's the point where I think, again, from a Drupal perspective, which is going to be different than a straight JavaScript app, than a straight JavaScript app, you're going to be calling or including those, like, as, you know, as Yes, modules are loading up some functions. But in Drupal, you don't necessarily know where the file is going to live. And so it's really hard beforehand, unless you're very opinionated, to say, oh, yeah, I know that I'm gonna load this library because it's loaded here. And now I can do that JavaScript, versus with Drupal, people put things in different places. So that's why I like to use the library system to help me manage it. And then once it's on the page, I just use it.

John P  
So going back to like, just basic HTML, right, like so it's basically just loading load loading JavaScript. And then it's the browser's kind of using its API to figure out where things are

Nic L  
well, yeah, but there's, there's an important distinction to actually, because there's, there's kind of two levels to this. What you guys are talking about right now is kind of on the integration side, right. So on the integration side, you already have a native web component, and you're basically telling Drupal using, I mean, I don't know how you do without using library system, it'd be kind of bizarre not to, but you're basically telling the library system, this is the JavaScript for this library, then you have a twig file somewhere that says, okay, when you're rendering this piece of content, or this paragraph, or this, whatever, you attach this library to it, which then Drupal uses to touch the JavaScript, and then output this HTML. And that HTML is, the custom element that you created, with attributes placed with is supposed to go. So that's the integration side, you're basically telling Drupal, when this thing like the way you normally do a twig integrations, when this take twig template needs to load, you need this JavaScript library. And this is the HTML, you're outputting. But on the native web components side, you're also defining HTML structure, and styles for the Shadow DOM. So in this simple case, let's say you have a custom custom element where you're passing in a color and some text, right? You might have a, your shadow DOM structure might have, you know, a span that takes the color. And then a p tag internally that takes the text and inserts it right. So you, you, you can define the internal structure of your native web component separately, from, you know, the native web component itself. And, and there's a bunch of different ways that you can do that. I mean, most the most basic examples are just inline your styles or inline in the JS file, your template is inline the JS file. But if you're using build tools, you can kind of separate those into into separate files.

Ron N  
And that sort of template, the template and the slots be strapped to fit in.

Donna B  
As in say, we're talking about Shadow DOM again, I'm wondering before you say something about slots. What are those? How are they used? I'm sorry, I'm still catching up on some of the speeds of it.

Ron N  
Well, this is, you know, this is dark magic, like no, no question. Right? So awesome. So the, the template is actually an HTML element now. And so you can actually put it in JavaScript, you can actually put it in HTML. And it just kind of gives you that structure that then JavaScript can grab and use. It's a framework. And then slots are another one. And slot is kind of like a place. You can almost kind of think about like a region in Drupal, but it's more specific, where you can, yeah, it's a place where it's like, okay, I have a slot here. I'm gonna put stuff into it later. I don't know what I don't even necessarily know what it's gonna be. I just know I've created a component, I put a slot. I've got some ideas about how it should be used. But then when I give it to you, you're going to take it and you're going to be able to say, Okay, well, Ron was using it and he was putting this stuff into the slot. But I'm going to use the same thing, I'm going to put different stuff in there. And depending on how the component was created, it may be very specific. Or it may be very general, in which case, you put whatever you want. So it makes things a little bit more reusable.

Nic L  
So what's so two? Yeah, so a couple of examples, like specific examples of how we've used slots, because there's kind of two different types. There's what's called named slots. And there's anonymous slots. So for example, we have a component that we call a grid. And this is this is one of those examples where it actually is kind of layout even though usually you don't do layouts. So we have a component called grid. And we have an anonymous slot. And basically, that all the grid component does is you can pass one attribute that says columns, like should it be two, three or four columns? And then there might be there's, you know, an attribute, like, do you want break lines between the rows? So if you say, three columns and give six items, do you want an HR between them, right, so those are the two attributes, then we have an anonymous slot. And so the anonymous slot basically says, anything that's within me, put it here in order. So then the person they can put whatever cards they want in there, they can put in other custom components, they can put images, they can put text, they can put whatever they want in there, it's just going to basically put it in side the component, and it will say, Okay, I'm supposed to be three columns and push it into three columns, right. The other thing you can do is, say, a name slot. So you see, you have more than one slot that you need to assign to different areas of your native web component. A good example is an eyebrow. So let's say you have a little eyebrow that you know, a little bit of text with a tag on it or something. And you need that to go between the image and the, the description, right? So you say this slot, the name is eyebrow. And then when you're rendering that you can basically say, Hey, this is the eyebrow piece, and the native component will put that there. And then maybe you have a CTA slot. So at the bottom of that you have a CTA. So you have a slot that's named CTA, it's going to push it in that CTA section. So like Ron said, it's a way to take content that's internal to the that's internal to the component and just put it there. And it's, it's great. Because again, this is this is kind of a technical detail. But it's great because that slotted content, technically, is like Dom, which means that it can be styled by the parent website. So if you were if you were doing it with something like a grid, you can say, hey, this is a grid. This is how it will get handled. It'll handle all the automatic like reshuffling and stuff and responsiveness. You can style it however you want it, put whatever you want in there in this component, we'll we'll lay it out properly.

Ron N  
Because you can pierce the Shadow DOM with the slot because this is why right, because it's just yeah.

Donna B  
That's a good way it sounds like to make sure you have headers on all of your, your grids and all of that good. Yeah.

Ron N  
So that's, that's interesting, too, because then you could have like, let's say you, you had like your grid example. And for you have like a title for that grid component. So it's like, you know, upcoming events or something. And you could style that a specific way, just because it's like, it's a heading. But then if you were pulling in inside the slot, whatever those other cards were, those wouldn't necessarily interfere or be interfered with by the CSS inside that shadow DOM because they're still pulling from the light dom

Nic L  
Exactly. And, and one of the reasons why you might want to do this is for in our cases, you can do things that aren't really well supported yet in browsers. But because you're inside of something you can you can control that really well. So for example, one of the things that this project did with like these grids is, we introduced container queries. So basically, you know, everybody on the call is familiar with responsive design, right? You you kind of respond to the width of the viewport. And sometimes we respond to the behavior like is it a touch device or not. But in our particular case, we can't rely on that, because we don't know. We're going to provide training and guidelines and things like that. But we don't know for sure that a developers putting this grid in a full width, layout, they might be putting in the layout as a sidebar, or they might even just be putting it in the sidebar. So we have, you know, mobile designs that look great. I mean, it's mobile first project. So you know, it would actually look great in that sidebar, but we can't depend on the width of the viewport because it's now been squished into something that's 250 pixels wide. We need it to display the mobile layout At web, so we were able to because it's native web component, pretty easily have it determine the width of its container and apply the correct styles based on the width of the container, rather than the width of the device that its on. Which means that if they put it on something that has weird padding that we're not expecting, or in a layout that's not expecting, we can be confident that it's going to look good, because it's responding to its parent containers with not ever the width of the viewport. Okay, so we are getting towards the end of the show. I'm curious. You know, now that we've gone through all this, we've dove deep, this has been a bit more technical than most of our shows. Our listeners are probably somewhat excited about them, and maybe a little intimidated. I guess one of the questions is, are these ball supported? Are they something that people should look into?

Ron N  
Pretty much, yes, you can go and look up for any specific things you're trying to do. But generally speaking, except for IE, rest in peace. You can pretty much at this point, rely on on all this functionality. I think as you point out, though, there are like, you might run into some weird edge cases, we are kind of dealing with some strange things. So there may be some places where you have assumptions about how things should work, that they may not, and there may be some edge cases where apart. Thank you. Yeah, I didn't want to say it. But where things don't quite work. Maybe the way they should. But, but generally speaking, I would not shy away at all. Definitely something fun to use.

John P  
So Web components.org has a table that shows support. And all the major browsers even Safari do have stable support for Yeah, HTML templates, custom elements, Shadow DOM modules, modules. So yeah, so far, as far as wonkiness could just be could just be the

Ron N  
way sometimes the way they implement those things.

Nic L  
Yeah. Safari is the new IE, they they Oh,

Ron N  
shots fired.

Nic L  
As a backend dev who has very little front end. I've been hearing that through the grapevine.

John P  
That's it. That's the last time you'll see our podcast on Apple podcasts. All done.

Ron N  
That's fantastic.

John P  
So in wrapping wrapping things up here. Ron, is there anything else that we should we should cover that? You know, maybe our listeners should know about? I will say before you answer that. The last five minutes, I have lost myself on web components.org. And found found a funny little component library from Adobe called the spectrum web component library. And I don't know it looks pretty easy to implement and to start using, you know, they have interesting like tooltip, component and, and all bunch of different things. So anyway, getting back to the question, anything else, our listeners need to know that we did not cover?

Ron N  
So I think we have covered a lot of this stuff. The one thing I would say is, don't be intimidated. Because I think one of the things, the challenges I've seen is that there are a lot of people who are traditionally back end developers, myself included, who don't know as much about the front end, they don't know as much about semantic HTML or accessibility, or how these pieces fit or the latest and greatest JavaScript frameworks. And it's just a whole other thing you don't think about the other side of the table, you have, you know, front end, people who know, typically, they don't even want to know about Drupal, or about PHP or about how those things work. And the middle ground between where they meet, I think is an area where we as a community need to do more looking and more investing. It's not as scary or confusing or complex as it used to be. So like, on the very, very easy side, you have, there's a module called Web Components, I believe, that I think will actually allow you to pull in pieces directly from web components.org. So super easy to use there. I mentioned the component module a number of times or other modules that are very similar, that offer similar functionality that basically it's a very easy way to allow you to take web components and get them into Drupal and use them in Drupal as a site builder without having to create like, plugins or library files, or you know, so if someone who leans more, you know, on the JavaScript side and they don't want to touch that gross PHP stuff, this is a way for them to do that. But also if you're a Drupal developer on the back end, and you want to start dabbling. And it's a really, really easy way for you to jump in. And I've seen even less experienced, like sales engineers and people who don't have a PHP developer background, jump in and be able to like, okay, I can go grab something from you know, code pen, or I can play around with some sample code and here's a really quick and easy way for me to get it into a Drupal site and start playing around with it. So highly recommend start playing with this stuff if you haven't a lot of value and a lot of cool features that you can do.

John P  
Very cool. Well, Ron, thank you for joining us. It was great talking with you as always, and I look forward to having you on again.

Ron N  
Anytime just know you by mail and I'll just keep talking. So good job. Good job on y'all for training me and that's really, that's that's a pro move on that one.

Nic L  
For our listeners, do you have questions or feedback you can reach out to talk in Drupal on Twitter with the handle talking Drupal or via email at show@talkingdrupal.com You can connect with our hosts and other listeners on the Drupal slack and the talking drupal channel. If you're interested in show news, upcoming Drupal camps local meetups and Chad's book corner, you can sign up for our newsletter at talkingdrupal.com/newsletter

John P  
you can promote your Drupal community event on talking Drupal. Learn more at talkingdrupal.com/tdpromo.

Nic L  
And thank you patrons for supporting talking Drupal, your support is greatly appreciated. You can learn more about becoming a patron and talkingdrupal.com and choose become a patron.

John P  
All right, we've gotten to the end of our show. Ron, if folks wanted to chat your ear off about native web components, how could they go about doing that?

Ron N  
Typically, it's rlnorthcutt in all the places so Twitter and definitely drupal.org and I'm I'm rounding about in in Drupal Slack community events can find me tell me tell me what you like tell me what I got wrong to how t make it better.

John P  
Awesome. Donna, what about you?

Donna B  
On LinkedIn or on Drupal slack, I'm donnabungard on Twitter, or most other places I'm dbungard. So yeah, reach out.

John P  
Awesome. Nick Laflin.

Nic L  
You can find me pretty much everywhere at NICXVAN

John P  
and I'm John Picozzi. You can find me on all the major social networks and drupal.org @JohnPicozzi and you can find out about epam @epam.com

Nic L  
And if you've enjoyed listening, we've enjoyed talking see you guys next week.