Web Components

SPEAKER:
I guess we can start chatting, just the the four of us in a robot, but certainly happy to talk. So, I guess the first question is if anybody had anything specific that they were interested in want to talk about. If they have experience with what components in general? Start there. Or if people were looking to just hear things. OK, Brian. Can you hear me? I can now. Yep. OK, good. I attended one of U.S. (INAUDIBLE) duplicable in the last year and I'm interested to see what you have today. Great. Cool. What else about (INAUDIBLE) what brought you here today? Well, I'm just looking over your slides from that you had linked in your description right now, and it's sort of cool that there's a way to make a Web component without having to do react or view or so I'm addressing to get a little more information and understanding on that. I think it's a good way to be able to have components and not have to go all the way. Yep. Yeah. There's definitely, you know, some quirks and challenges. But I think long term, I'd like to think this is where it's headed.

We'll see. How about (INAUDIBLE) what what brings you here today? Perhaps he is away from his computer. How about Chris? Yeah. I am here, Bryan. Yes, I'll turn the camera on as soon as they get through lunch. Sorry. That's fine. But now, I just I think I agree with your sentiment that web components are where things are going. And I don't do Drupal day to day these days so just kind of curious to hear what people think and kind of understand what kind of impact it will have on the way we approach Drupal builds, especially. I think it's interesting as a lot of the projects we're seeing come through now. What I would consider traditional Drupal builds like them, not just Drupal they have ideas where you need to get content to other channels. And so, you know, if there are ways that we can build components that can be leveraged across channels, I think that's kind of interesting. So, given all that, it's good to know what everybody's interested in, maybe I can just spend a few minutes cherry picking a few of those slides that I have, just talking about kind of the basics of what a Web component is and then see if we have any questions from there.

Also, kind of given the small group and what folks seem to be interested in. One thing that I'd love to do if we have a little time related to the Decoupled Menus initiative in Drupal. I've been working on a Web component for that. I'd love to demo kind of what we have so far and just see what people think. It's certainly pretty early, but that would be fun for me. That sounds good. Awesome, I will share my screen. OK, let me see if I can make this, I think I can. Start at the beginning, but all good. Yeah, so, I won't do the full song and dance necessarily for all of this, so in past posts about this topic and just general conversations I've had with people and also from my perspective, when I was starting to learn about Web components, I still don't consider myself an expert by any means. The distinction between like what a 'Web component' is versus like things like react. angular, view or any of those frameworks that distinction was kind of unclear. They are like all components and all ways to build with components that primarily use JavaScript.

But I think it's important to talk about what makes Web components a little bit different. So, what makes them different is that it's actually a set of Web standards, a set of Web platform APIs, and they're not tied to a specific framework. So, it's not like choosing react or angular or something like that. And they can even be used with other frameworks. So, you could use a Web component that you built in a view project, for example, which certainly can open up the, you know, kind of cross framework possibilities here. And so the three pieces, three kind of main APIs are custom elements, and we'll look at some quick examples, but that's basically the ability to create your own custom HTML element, just like, you know, H2 or div. You can, using this browser standard, create your own completely custom thing that you can just use like any other HTML tag. And then the shadow DOM is a little bit more complicated. So, the browser itself has the DOM document object model where you can select different things in the browser, the web components interest, the idea of shadow DOM, which is it's completely, it's own, completely isolated DOM that's specific to the instance of the component.

And that does things like prevent styles from leaking into the component and isolate it in some pretty interesting ways. And then the last piece, which is I'd say probably the the least important part from my perspective, but still important and useful is the concept of an HTML template. There really isn't a way in HTML as it stands to easily create a reusable template. There's a lot of templating engines that do that, but this also introduces that concept as well. And also, anyone feel free you know I won't go too long with this, but if you have questions as we go along feel free to jump in. So, the fact that one thing that got me curious, I like building with components, but haven't really yet found a way to get us into my day to day work for. So, that kind of got me curious about learning more and understanding more. And this is a pretty interesting example. I don't know if anyone here has used the can I use website so you can search a particular TSS feature, JavaScript, feature something native in browsers and see the support it has across common browsers.

Great tool. And if you search web components, you can see the different pieces of the spec, the support that they have. It's important HTML templates. HTML imports are kind of an abandoned spec, but HTML template is what we're talking about. But the general story is that support is pretty good now, unless you want to support I11, there are poly fields for that. So, it's definitely possible, but it's of less pleasant. But if you're on modern browsers, this is definitely supported well across the board. But the other cool thing, if we actually just look at this site and inspect it, it just so happens that the can I use website actually is made up of a series of Web components, actually, if we inspect the table here, there's a custom element, the CIU support table, and you'll see that has its own shadow DOM. And then inside of that, there's some kind of more traditional markup that we're used to, but then other Web components inside of that. So, your browser support for each of the individual columns.

So, it's pretty interesting that this kind of commonly used resource itself is built on a series of of these custom components. Alright, so just a little bit more on, I'll skip through some slides, they did build out an example for this talk that was kind of fun, but let's just dive a little bit deeper on each of the three pieces, the custom elements, and shadow DOM, and HTML templates. So, the custom element and this actually is the codependents screenshot references. So, I created this election result tracker and that created this results hyphen tracker custom element. I think they have to have a dash in them so that they don't conflict with the top level HTML elements. But, so this custom element, when you just use it like any markup, it's going to render, you know exactly what the custom element is created to render in this case, this results tracker. But also it can take in attributes like the headline and the total and data for the candidates. And that can be passed down to the customer element and used when it renders.

If you're familiar with react, for example and MGSX you know, this is more the kind of traditional HTML markup with some of the same concepts about like passing in data are pretty similar. So, you know, obviously there are a lot of additional subtleties to that, but that's the basic idea. You can create your own custom purposed HTML element and you could create it in the scope of a project, or you could make something that you distribute and share too. And the shadow DOM. So, this is the idea that custom elements have their own little DOM tree and it's scoped to that component. So, things from the outside can't impact it. So, if you're using JavaScript to select elements and DOM, it won't see into the shadow DOM. And you can also add styles to your component and those styles will be scoped to this shadow DOM. So, you can create a rule for H2 that makes all H2's red and that will only happen in this shadow DOM and wouldn't happen to the other H2's on a page. So, it's a way that these components can be really, well, isolated.

If you're making something like think of that election tracker that we saw before that you wanted to distribute and you wanted it to look the same way, regardless of where it's used. That's a really good application for that. But it does mean that doing things like using global styles can be more challenging, which you're probably used to with regular HTML element styling. There's definitely some ways to handle that, but it's kind of different way to think about things for sure. And then see where I have a... This is actually I don't have a separate slide, but this is just a quick example of what an HTML template looks like. So, in JavaScript, in this Web component, you can define a template element, and that really is just a set of markup that can then be used later. It's actually when you create it, it's not automatically referenced in the DOM. You do have to, like, actually apply it to your Web component, shadow DOM, for example, for it to be used. So, it's basically just a way to create, you know, reusable template that you can either use in this component or reuse across others.

So, I mean, I think why this is a little bit less interesting to me is because it almost seems like something that, you know, should already be there or that we've been been doing forever because we're so used to working with templating language is like Twigg. But it's also pretty important to be able to make these a little bit more pleasant to build. So, that's like, you know, I don't especially if people have questions or other things they want to talk about, I definitely don't want to spend the whole time just talking. But was that a useful overview? Do people have any questions or kind of anything else they'd like to know more about if this kind of brings to mind? I also see a couple of people joined us. Hi. Anybody there? Any thoughts? Sorry (INAUDIBLE) So, when you're thinking about Web components, Brian, like how do you decide that you want to use them or for how many, how many you're going to build? I have obviously that really a front end developer. So, when I think of components, I think of like it's the menu and it's the hero banner and it's the things like that.

I mean, is it roughly translatable and how do you decide this makes good sense to build with the Web components? This I should just make a block and Drupal. Yeah, that's a good question. I don't know that I for specifically Web components, have a really clear answer there. Still kind of figuring it out. But for me, like the biggest thing is reuse. If it's something that you're going to use in a bunch of places, be it within the scope of one project or especially if it's across multiple projects, abstracting out into a component should make it easier to use and more repeatable and predictable. So, that's kind of how I think about components in general. And then figuring out where Web components fits into that general concept, I haven't quite made my mind up yet. I don't know if that answered your question at all. I think it seems like maybe there's still space in this area to kind of grow to get, I don't want to say best practices but to figure out that stuff. Yep, yeah, I mean, you asked about menus I can use this into to demo my little menu thing and that might give you some ideas.

So, do the quick summary here, so for the decoupled menus initiative, I don't know if people have heard about it, but it's an initiative to basically add additional API support to Drupal to make it easier for people to build Web components in their framework of choice. And what people are focusing on first is menus. So, there's a new module that's being worked on that exposes like a new menu and point to support this. And then for Drupal kind, they're encouraging people to try to put together a bunch of components to exercise. So, because I'm interested in this initiative and also Web components in general, I started working on building out a Drupal menu Web component. So, I have a project that I created for that. So, here's the super quick demo with something like a menu. And this might kind of give you an idea of how this could be used to abstract things. So, I published this on NPM (INAUDIBLE) still super early, but... So, and what I'm trying to do here, and it might evolve over time as people contribute to it, but the idea is that the components that were are being created as part of this project are really generic so that they could be used on a bunch of different sites and theme different ways.

Like it doesn't have really any opinions about styling yet, but even when it's fully built out, it would have pretty small opinions about styling. But, so this is published on NPM. So, there's a couple of different CDN that offer this package now, including this one called Skypack, which make it really easy to just use something like a Web component in HTML. So, I will just open up a code pen. Alright, (INAUDIBLE) pen has nothing in it, so the first thing that we can do is import the script. So, again, this is like the simplest, most lightweight way that we could do it, importing it from a CDN all we have to do is do the script type module and then import it. You also could use this with a build process and installers and then NPM package and do all that fun stuff with wet pack or whatever bundler you're using. But I think it is pretty cool that you literally could just drop this in on a blank HTML document. And then we can use the HTML elements, so it said namespace with GDWC, Generic Drupal Web Components and then menu.

So, if we just did that as of right now, it would render anything, there's a couple of attributes you need to pass to it. So, branding is going to be like the title for the menu. So, if we do that, we see the menu title is displaying on screen, so all we had to do is just import this one script and then we now get access to this menu web component. And then so with this decoupled menus module, there's an endpoint that gets exposed. So, if you want to use this with a Drupal endpoint, it takes two other attributes. The first being the base URL. So, I'll just grab this here from this example menu endpoint and put that in. And then the other thing is the idea of the menu, so the name of the menu that you want to use, so menu ID equals mean. And then, boom. So, this Web component has all the logic for that, and it goes out to that endpoint and it gets all the menu data, passes it. And right now, it just is spitting out a list and unordered list of all the menu items. But, you know, I think this is kind of an interesting concept in really trying to abstract away like all of the, you know, everything you need to do behind the scenes to talk to this API and just make a really simple, easily repeatable thing that hits a triple endpoint that we know is going to have a particular structure and just spits out menu markup that you can use anywhere.

So, that was the demo I wanted to give, but somewhat related to what you're asking I think. That's pretty cool. Yeah. I also see some other folks joined up. I don't know if anybody has any questions about Web components or experience with them that they'd like to share. Certainly happy to hand over the discussion to anybody who has anything they want to cover. And alternatively, I also will talk forever if there is. But yeah, so with this project specifically, if anybody is interested in doing more work with Web components or the Decoupled menus initiative, I think there's an initiative day on Tuesday at Triple Con and I'll be coordinating some sprinting throughout the event, trying to work on this more so could use help from anybody who's interested. Another interesting thing, if people don't have any questions or particular topics, you know, again, just kind of thinking of a Web component as being like a generic browser standard. Let's see, there's a site, Web components everywhere.

And this goes into and it kind of lays out for all of the different frameworks, how well they support Web components based on a handful of different tests. So, how easy it is to use a Web component inside of another framework. And, you know, you can dig around it if you're curious. But the short story here is that for the most part, support is pretty good. So, there are kind of common conventions and support for using a Web component that's not specific to a phone, but using it in another framework like angular view. The one interesting catch is that react has some limitations. They probably rate the worst out of all the framework's here. There are a bunch of issues where there's talk about trying to make improvements, to react, to handle this a little bit better. And it's definitely possible. There's an example in the slides that we're looking at before using a Web component with react, but there is kind of a lot more boilerplate to get it to to basically to get react to pass events and stay into the Web component.

So, it's Bulmer that react specifically has some work to do here. How likely are they to make those changes? That is a good question, I would say, having looked at some of these issues, maybe not super likely, a lot of these issues have kind of been struggling along for a long time. I think what will happen is that they will make those changes as Web component adoption increases. So, I think they would tackle it when they essentially can't get away with not doing it anymore. So, that's at least one consideration when you think about what components? Yeah, if you are familiar with reacts, comfortable to react, want to use react. Yeah, I think there isn't quite as stronger case you know, in a lot of cases might be better off just building the thing and react. Anything else? I'd love to hear from anybody else who joined late, if you have any questions or views Web components before. But also, again, totally fine, you may be eating your lunch, drinking a delicious cup of coffee. You know, someone that really is obviously pretty new to the Web components and you're kind of going through it, getting getting to know the things as well, like where did you start?

What are good places for people to learn more about it, is it really websites and things, are there books? Are there certain people kind of pay attention to? Yeah, that's a great question. I actually found it difficult to find really good clear resources. The NDN page on web components is pretty good, but like as far as there being like a really kind of clear fun tutorial, I haven't yet found something like great or definitive. So, really what I did is just kind of started building things and then ran into things that I didn't understand or, you know, problems and then tracked down more specific articles, which is not necessarily the greatest experience. Some say about an opportunity for somebody? Yeah, I actually did. I purchased a domain related to that particular topic, amusing Web component, related domain. I just haven't had the opportunity to be that guy yet. Nice. And if people don't have anything specific on this topic, we could certainly wrap up or if people, you know, I'd love to hear how people are just enjoying the camp.

We can talk about anything if people don't have any Web component, specific things. I'll put in the chat I found CSS Tricks article that is an introduction to Web components. I don't know if that would help anybody, and then I think I found a Web components crash course on YouTube that traversal media did also pop that in. That's great. I haven't looked at them personally myself, but doing a quick Google search. Those are the things that came up. CSS tricks stuff is often very good, so that's cool. And it's an article series, it's actually five parts. So, the first part is an introduction to Web components. And then part two is crafting reusable HTML templates, and part three is creating a custom element from scratch. Part four is encapsulating style. There you go. I don't need to read it out. It was nice. It was nice to hear your voice. Yeah, that's great. That is excellent. Thank you for sharing that, that actually also brings to mind another interesting wrinkle related to Web components and kind of the supporting libraries here.

So, let's see what their code examples look like. So, yeah, so this looks to be using just kind of the browser native web components back. What's a good example here. Yeah, this is actually a pretty decent one, so I'm trying to think of a way to summarize this quickly. So, the browser native web components can do all of those three things, obviously, that we talked about, the three pieces of the API. In building some things using this, there were definitely some cases where it felt to me like a lot of boilerplate, for example. And this attribute changed callback is a pretty good example of that. So, thinking about like something like react, if you have a prop that you're passing into your component, you know, you typically want if a new prop gets passed in or the state of a component updates you want to automatically re render and web components can do that, too. But to do that with the kind of baseline web components back, you have to use this attribute changed callback method. And when a particular attribute change, you typically will check it against the old value, check the old value against the new value to make sure that it actually changed to a new value that you do unnecessary reminders.

So, you potentially have to like write that logic yourself every time. But there are other supporting libraries that can help with the developer experience here. The most common one, by far from what I've seen anyway, is a lit element, which is a Google project. Another popular one is Stencil, and there's a handful of others as well. And it might feel strange to think about obviously, one of the great premises of Web opponents is that you don't require a framework. But now we're starting to introduce things that feel like frameworks. But I found using lit elements, for example, that it seems to strike a pretty good balance in that it does do some things to make the developer experience a little bit better, doesn't things better with templating, but pretty much everything that it adds or improves is pretty directly related to the baseline web component APIs. So, it would be pretty reasonable if you did decide I don't want to use that element anymore, like Google varnishes someday to be able to build the same thing using without that library.

Here's a good example of you know, kind of some of the niceties here, so if we saw a headline in a component, define it as a property here and say that it's a string, then lit element will automatically handle checking if an attribute changes and re rendering. Also if your attribute is like a type of array or object, it will convert that into a string because the attributes at least of their attributes must be strings. So, it handles a lot of that boilerplate that you'd have to write. And again, I think it's... When building whatever building lately with Web components, I do use lit element. And I think it is close enough to the fact that I don't feel like we're getting back to like a reactor review. But then alternatively, something like Stencil, I feel like goes a little bit too far in that describes itself as a compiler that generates Web components and it actually adds things that really aren't part of the the main Web components API like it's own virtual DOM. And you can use JSX like you would use and react and all kinds of things.

So, for me personally, that feels like it's going a little bit too far and it would be hard to take something like this and create (INAUDIBLE) Web component with it. Cool. Any other thoughts, comments, things you want to see? I think on the schedule, we have five more minutes. Has everybody been enjoying Midcamp? It's been good and enjoyable. Now, it's different doing it virtually, but we had that last year, too, so I think the change up in format makes it a little more entertaining. Yeah, it'll be nice when we can be in person again, but also at the same time, I think it's great that people outside of Chicago can easily attend to. So, I think we're trying to have some sort of hybrid approach next year. Not that the drive from Ann Arbor is too far, but, yeah, the parking is Chicago. Cool. Well, unless anybody has anything else, we could wrap up. I hope this was interesting and it was nice chat with everybody. Sounds good. Thanks, Brian. Thanks, Brian, for this wonderful intro. Excellent.