dylanjha

In my 13 years there are a lot of technologies I've never used. Maybe there was opportunities where you could have, or maybe things are working just fine for the problems you're solving and you don't need it, which is fine too.

Comment · 2 years ago

Styling components nested inside other components can still work with either slots or scoping CSS custom properties with parent selectors.

.login-form { --button-outline-width: 2px; }

.credit-card-form { --button-outline-width: 2px; }

Of course, the component needs to be authored & documented in a way that supports this.

For example, shoelace has a "Drawer" component: https://shoelace.style/components/drawer

By default the drawer component has an "X" button in the header to close it. If you want to override that, instead of trying to style the nested "X" button you can pass in your own header actions with slot="header-actions"

Comment · 2 years ago

> think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components

This is the inherent tension. It requires good web component authoring to expose:

1. `part`s that can be accessed by application-level CSS

2. slots for the application developer to inject html

3. CSS custom properties (--variable) -- these pierce the shadow DOM

The web component authors have to be very intentional about these things. There are good examples and bad examples and I think people are still learning how to do this well.

Comment · 2 years ago

I see. Particularly with CSS there's more of an enforced contract around how the element internals get exposed for styling. If the element hasn't exposed `parts` or slots it's hard to hack around it.

More broadly speaking I have found myself getting thrashed by the ever evolving "best practices" in the React ecosystem. First: write everything using class components, and then a couple years later everything should be written with hooks.

I think the benefit of web components (for certain things) is that the APIs and the standards move slowly. Something you write today isn't going to feel obsolete in only a couple years.

Comment · 2 years ago

(author from Mux here) -- that is correct. For the stuff we build for in-house use on mux.com and dashboard.mux.com we have a components library written in React.

You nailed it that we are shipping SDKs with visual components (like a video player) that need to be compatible across all kinds of frontends.

Instead of N number of SDKs to maintain where N is every front end framework, we have 2: a web component, and a React wrapper around the web component. Maybe in the (near) future we only have to maintain 1.

Comment · 2 years ago

(author here) I think the problem might be more around bureaucracy mixed with bad & buggy code than it is a specific problem with web components. Can you expand on that?