re: Lets Build Web Components! Part 8: Mythbusters Edition VIEW POST

re: Awesome and curated myth list, Benny! Currently, we are creating a design system in my company, but we are thinking in throw away using Web Compone...

Yes those are important considerations, and shadow parts will solve many of them. In the mean time, one approach would be to slot in elements you need to style from light DOM. Alternatively, expose lots of custom properties.

As for interpolated styles, CSS custom properties and the style attribute are the preferred route for now. I expect to see some nice patterns emerge as Constructable Style Sheets gain traction.

As mentioned, you could also take the approach of not using shadow DOM, but I think that would be a loss.

WRT color, inherited properties should pierce shadow boundaries, so this sounds like a bug. Repro?


I've solved both of these problems using CSS Properties.

In their stylesheets, ck-icon and ck-text would both use a custom property:

  color: var(--ck-text-color, #333333);

Then, in ck-button (and any other element that manipulates the background color):

:host[kind=primary] {
  --ck-text-color: white;

We've solved your second problem by side-stepping it whenever we can - when we use attributes (like your 'kind'), we set styles based on the attribute values, often in the form of a bundle of CSS properties that get used elsewhere in the stylesheet.

For more dynamically-computed styles, though, you are kind of stuck. The Shady DOM polyfill stamps out its template and styles once for each element (I think this is done for reasons of performance). One thing we did was call back to the ShadyDOM polyfill with a different element name (my-element-{hash of state}) for each state we encountered (though you should be careful, as this can easily backfire). Or, you can, as Benny said, just set styles directly on the element. It's maybe not the prettiest solution, but it works!

Joseph, my-element-{hash of state} is a really slick work around to the dynamic styling issue. The idea of "re-defining" your custom element on demand like that is actually pretty central to the way Skatejs approaches elements and their define package could be seen as a pretty fleshed out helper to intersect the two concepts.

So, we don't actually redefine the entire element, we just define a new template for ShadyDOM to play with. The actual code is here. I wouldn't reuse it verbatim, as it makes some assumptions that are very specific to us (like that, 99% of the time, our theme elements don't change their template once they've been stamped out the first time, so we don't need to worry about advanced diffing and such). We're also using a slightly older version of the polyfill, so it's possible that ShadyDOM has some new features that would get rid of some of this code.

code of conduct - report abuse