Check out a free preview of the full Web Components course

The "Web Components FAQ" Lesson is part of the full, Web Components course featured in this preview video. Here's what you'd learn in this lesson:

Dave answers some common web component questions including React compatibility, accessibility, IE11 compatibility, reactive contexts, SEO, and server-side rendering. Audience questions about handling focusable elements and the CSS cascade are also covered in this segment.


Transcript from the "Web Components FAQ" Lesson

>> This will be the final segment, hopefully wrap up pretty quick here. But this will be kind of questions and answers and so if you have some final questions or whatever, just get them down and get them ready. But I'm gonna do a quick rapid fire of some like common internet [LAUGH] people questions that I get that might be helpful or head off some questions you have.

React, we kind of talked about short answer is yes, right? So there's two things this Lit labs has the React wrapper, so you just consume it into your web component your lip project. And you can do that but also react 19 very promising or the experimental branch of React that we think will be react 19 looks promising.

And so it may be a great time to start looking at web components if you wanna know how big distribution and react accessible, this is a question that comes up a lot, obviously it's important. The short answer is yes, web components are accessible as you write them, right?

Like, it's easy to write inaccessible code but there are a few tough spots in regards to labeling and focus behavior. If you can think of it, like you have my input element, custom my input element, and you have a label outside of that. But how do you associate the label with the shadow thing?

So there's there's a few talks and sort of like that delegates focus attribute where if you click the label a delegate the focus into the element, the input element. But the issue is kind of with labeling is how do you delegate a label or something like that. So there's some specifications happening within the AOM accessibility object manager.

But then through the open or sorry the web component community group there's some work happening there it seems promising. But just know that if you have a label outside of the input like a custom input element you maybe have a problem there you have to yeah, you're going to have test it.

Make sure you figure that out that stuff's hard labeling and associated with hard, but then seem sort of thing with focus if you pop, open a dialogue and you go. Go into emoji picker, there's one an emoji picker, right? So if you open an emoji picker and you start driving around the emoji picker and you hit escape, how does the Shadow DOM know to go put the focus back on the thing that was last focus?

Cuz it has no knowledge of the stuff outside of it, so that can be tricky and you sort of need to like either mute an event or something to like restore the focus or to the previously active element. There's also a new inert attribute in HTML. I don't know if you've seen it, but it's basically says take all this stuff and pull it from the accessibility tree.

And so you could see like a place like a dialog or something like that. You have your app up here in your dialogue down here. And you just say make the whole app in NERT while the dialogue is happening. And now make the destroy the dialogue, and then make this uninjured, and then in theory, the focus should go back to where it was previously.

Again, that stuff is hard in normal HTML, in JavaScript, and it doesn't get super easier in, web component land. So, that's all traversing shadow down, etc. IE11 short answer, yes, there's a poly fill maintained by Google. So, it should be good, but I would maybe say, think about the progressive enhancement quality superpowers of web components.

Maybe you don't need a polyfill. Maybe the LightDOMs enough to provide a suitable fallback for IE, which just won't even render a custom element. Another thing you might consider is support for internet explorer. It ends on June 15 2022. And that's usually the time when enterprise companies that are employing ie 11 and stuff like that.

They usually mass switch their entire company over because they're out of some support cycle. Who knows what's going to happen? But I would posit .I would say ,if you're starting a project today ,are you going to finish by June 15 ?And if you're not going to finish by June 15 of this year, [LAUGH].

Then maybe you don't need to worry about it. So I think most people are not worrying about it at this point so. Reactive contexts we talked about that yes, but it's sort of BYO for now. Frameworks are gonna try to help you here. And then, there is this context API kinda being discussed in the Web Components community group SEO is a good question there's actually a really nice post link to the guide book notes.

But there's two posts Googlebot itself Search Engine Land or whatever search engine hub or whatever on Google says Googlebot can flatten Shadow DOM and light DOM together. So a plus it's not clear if that happens on the first pass or the second pass that that the like, typically the like HTML pass and the JavaScript pass.

It's not clear which it happens on but it can do that. And then there's another post that sort of like went through like being and DuckDuckGo to see sort of how they index web components is kind of a big test. And it seems pretty positive I think being missed it in a few places so it might you may need to if beings a big audience then maybe it's important but I think this all get better as the crawler lawyers and everything get better.

SSR this is a good question. Server side rendering, like how do you do that right? We've been doing kind of everything in JavaScript in the client. That's a big deal. Well, there's a new feature called declarative Shadow DOM, and I'll show it to you right here. This is a web component.

This is my Bill Murray alert. But I have no JavaScript. But I have written a web component. And the magic that's happening here is this template shadowroot open. So if you put a template inside your alert, the browser. So chrome specifically the browser will say okay I know what to do with that I'm just going to try to render that on a pass.

And then when your component actually comes through later and upgrades it to be like fully interactive It'll actually tear down that old template and put in a new template or just upgrade your current template. However you have it. So that's cool. I think like, what I learned was, this might be another great way to provide kind of skeleton content to provide some content.

What I don't like about it if I'm completely honest is, if I'm just writing the whole template inside of here. Maybe I should just use PHP just to get the server rendered. That's a totally valid opinion in my opinion, because it's my opinion. And but the I think we're all using some kind of preprocessor of some sort, whether it's a static site generator or something.

So maybe there's a way that you can do that efficiently and not, you don't have HTML in one place. And script in other place or maybe there's eventually a tool that will be able to, recognize your template and then kind of automatically Pre parse that sort of stuff.

So I'm sure all that stuff is kind of in the works. But declarative Shadow DOM can do like very server side rendering that will reduce your paint times and stuff like that. Okay, any questions before I wrap it all up or chat as well? If you have questions, yes.

>> Do you have any guidance or Beck's best practices for focus locking? Finding all focus will elements are including elements within the Shadow DOM.
>> Okay, how do you find focus level elements in the Shadow DOM? So that delegates focus will find the first focus scible element. I'm not 100% clear on what rules it does to determine that, but it's probably like inputs and then tab indexes and stuff like that.

There's probably an order of operations that tries to fetch those and then tips for managing focus. Was that the question mark it was tips for focus locking focus locki yeah, so if you had this custom element and pop up thing pop up. How do you trap the focus inside of it.

I would honestly right now look at that inert attribute in the inert polyfill. And basically you insert everything else and then that little chunk of content becomes the only thing the cursor can kind of move around on. And then you destroy this and unaired that and then you're back to where you want to be.

So that would be my like, look into the inert attribute. It's being implemented, I think in Chrome, Safari and all kinds of things. So and then there's a pretty good polyfill for it. And so, one more question. Here we go.
>> How do you think about CSS property naming and usage in the context of web components, such as, prefixing variable names on a per component basis or defining them in a host versus defining them on route.

>> Right, okay cool yeah so how do you to like CSS custom properties if we're going to use that, I like the namespace, like your variables have the same name as your element like namespace. So you like that shadow scroller was like shadow scroller. What was it, strength or something?

So, how the radius. I like that because it's very specific and I know it's there's not gonna be a side effect. There's a chance if you name something at the top of your document, and then this custom element is looking for the BG. Attribute, there might be a conflict, cuz you set it up here, but you did not want it to go in the custom element.

Easy enough to redefine it because that's how CSS variables work. You can define something up here and then you can redefine it down here with no problems to the rest of the page. That's kind of the nature of the cascade. So there's less Less massive fallout than like changing a SASS variable or something.

But, in where should you apply it, at the root or host, I think it does not matter. I think people started using route colon route too further see their CSS variables just. Because I think some example used it doesn't have to be there it can be a body it can be on HTML we just for some reason route please everyone just gravitated.

We should just do that and that's, I don't know, weird, but host, I like host, just because you're saying everything in this custom element is going to be used one of these, but it doesn't matter. That's the nature of CSS. It just picks up where it where it does.

So it tries to figure it out.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now