|
I generally think the Shadow DOM is an antipattern. A lot of developers are really surprised to hear that. It's probably the opinion of mine that gets the most pushback. After all, when Web Components were first announced, a lot of early advocates touted the Shadow DOM as the killer feature of the API. It was a big part of the push to get devs from framework land sold on them. Let's dig in… What the Shadow DOM doesThe Shadow DOM provides encapsulation. It keeps your HTML isolated from the rest of the DOM. If you're used to building in React, that mental model makes sense. Hell, it's probably desirable! But if you're used to building with the grain of the web—taking advantage of the speed of raw HTML and the power of the cascade—then encapsulation is a hindrance. Your HTML doesn't load without JS. Your CSS doesn't inherit. Don't bring React thinking to the native web. When is encapsulation good, then?That said, there are times when encapsulation can be useful. I reach for the Shadow DOM, when…
While the first item is quite common, the second rarely is. Generally speaking, inheriting styles from the parent site is a good thing. I want my script UI to look like it belongs on the site where it's being loaded. One example that specifically comes to mind is some sort of third-party widget, the kind of thing you'd typically use an iframe for. An embedded map or branded widget of some kind. The thing is, most projects aren't that. Cheers, Want to share this with others or read it later? View it in a browser. |
0 Komentar untuk "[Go Make Things] When is the shadow DOM useful?"