I love the idea of web components, I just wish slots weren't tied to shadow DOM.

Anecdotally it feels like they arrived right as headless/self-styled component libraries started to pick up steam, and things inverted to the point that not being able to have your "external" styles easily apply to the component became more of a problem than them being affected by random stray styles.

Maybe I am missing what you mean, but I 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.

I wonder if that is the true reason OLE type systems have failed on the web, as there aren’t enough agreed upon preexisting widgets for it not to descend into an inconsistent horror show.

> 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.

Isn’t the problem that this is recursive? i.e. if you use a component which itself contains a component that contains a button and that button should be styled should the intermediate components be worrying about it? And does the end consuming application need to care when new widgets are added to components nested two deep?

It is almost like the need for styling necessitates all the old dependency injection and factory gunk that older frameworks became notorious for.

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"

Yes, that hits the nail on the head, the tension between encapsulation and access.

and you won the prize. web components are being rushed because it's getting too easy to use the internet without JavaScript thanks to the SSR crazy. and no JS is not good for google business

I'm not following, what makes a poorly written React component better than a poorly written web component?

When your company requires using them, it's more straightforward adjust the styles and event handling of a react component than a web component.

(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?

Thanks, I think you're 100% right, it's the red tape more than the tech. My issue is that when an in house React component is poorly coded, it's trivial to inject css overrides or select internal elements of the component to change it's behavior. With web components, the events emitted are locked in, each sub element or worse sub web component is nested away and only accessible via the shadow dom making edge case or hot fix solutions that much more trouble to deal with. In both cases the ideal would be for the internal library maintainers to fix the issues or support the required features, but with ever long lead times, it's often necessary to work something out at the project level. The working out is much more abrasive with web components though.

In practice, this update is great for usability. But it's a sign that web components are still relevant, extending my time dealing with poorly built ones.

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.

> select internal elements of the component

If you need an equivalent Expedient Field Hack for a web component, remember it's an HTMLElement subclass and ends up in the DOM. So you can get the object back out of the DOM as 'just another internal element' and gutwrench it from there (or, depending, subclass it and register your subclass, or insert an extra entry into its prototype chain, or ...).

I mean, yes, those are all horrible, but so's digging into the guts of a react component you don't own, sometimes taking a dependency on the internals of somebody else's code is the least horrible option.

... it occurs to me that given a JS Function's .toString() returns the source code, on an e.g. lit-html component you could probably even grab the render function, yank the html`...` call out of it, regexp that to tweak the mark up, and then use an indirect eval to stuff it back in.

But really, I think "you now have the element object, monkey patch it to taste" is probably quite sufficient and far, far less ridiculous than that last paragraph, I just couldn't resist sharing the horrifying thought :)

Yeah, worth noting that there IS an escape hatch for monkey-patching (at your own risk). So you're not totally out of luck. It is just HTMLElement all the way down

I'm in a similar boat. I have to use a 3rd party component library written in web components for our react app (esri/calcite-components) and it's a huge pain because * You can't override styles except what is exposed through css variables * They often encapsulate some internal logic which I can't control from React (tbh this could happen with a React library too)

Having worked with both internal company web components and internal company jquery-based components, I vastly prefer the former.

Yes, ad-hoc fixing styles and behavior from the outside is nice. But when every internal style/class/element is technically part of the API surface, you quickly end up with extremely brittle code.

Suddenly every tiny change (bug fixes, refactors, new feature) in the component library has the potential to break the app in unexpected ways, and the result is an inability to upgrade. Happens all the time.

With shadow DOM, this problem basically go away (depending on how it’s implemented)

I haven't used them. Why does "ad hoc fixing" require searching and boilerplate?

It shouldn't there's a lot of ways to use web components anyone with years of experience with objective programming should feel extremely at home. Where as react requires a lot of unnecessary overhead associated with security risks.

>Where as react requires a lot of unnecessary overhead associated with security risks.

Such as what?

Oh please. If we are going to complain about anything free and built into the standard it would be server side events which barely work at best.

Personally I wouldn't mind server rendered features like what react does but in the setting of not javascript.