Live data from Hacker News

How we use web components

github.blog

71–80 of 84 posts

Re: How we use web components

#71
We've started converting everything to web components using Stencil. Allows us flexibility to have the same look and feel no matter what framework we're using.

Took a minute to figure out how to get React/Vue components to render inside of a web component, but now we're all set.

Re: How we use web components

#72

I'm currently working on testing a UI with Selenium that uses Shadow DOM all over the place. It's hot garbage, and I have no idea why anybody thought this was a good idea. Something goes wrong in CI and you'd like to dump the DOM to figure out why? Too bad, the entire page is sitting inside a Shadow DOM, and you get to see an empty body tag and a timeout waiting for an element to appear. Want to click that button tha…

It's surprising how poorly supported Shadow DOM is across the major UI testing frameworks. To access a Shadow DOM element you'll typically need to write a JS shim that uses the DOM APIs to get at the element, and then do other tricks to work around things like closed vs. open shadow roots and handle how event propagation works with shadow DOM.

Shameless plug, but we're building a no-code testing framework (https://reflect.run) that does all of this for you automatically. Works great with Shadow DOM (both open and closed) as well as more esoteric things - for example did you know Salesforce's Lightning framework overrides how Shadow DOM works? :D

Re: How we use web components

#73

Earlier quoted context omitted.

Take a look at CSS shadow parts. It allows you to mark which part of the shadow dom are stylable which you can then access using the ::part() pseudo element. Another handy thing to know is that exportparts reexports parts from a nested web component, and CSS --custom-properties will cascade down into the shadow dom https://developer.mozilla.org/en-US/docs/Web/CSS/::part

I didn't know about that and it is certainly interesting, however for my particular use case it wouldn't have worked unfortunately. I was using Tailwind, so rather than targeting specific components from a global style sheet, I was trying to use the utility classes from the global sheet inside a web component.

Ahh yes. I believe the tailwind workflow is incompatible with the component scoped styles which web component forces. I believe however that when you use components scoped styles (whether through the shadow dom, React’s styled components, Vue’s single file components, etc) tailwind becomes obsolete (or rather the wrong tool for the job).

Re: How we use web components

#74
post #56

I'm currently working on testing a UI with Selenium that uses Shadow DOM all over the place. It's hot garbage, and I have no idea why anybody thought this was a good idea. Something goes wrong in CI and you'd like to dump the DOM to figure out why? Too bad, the entire page is sitting inside a Shadow DOM, and you get to see an empty body tag and a timeout waiting for an element to appear. Want to click that button tha…

IMO the shadow DOM should be used sparingly and in most cases not at all. You can use web components without the shadow DOM (I've seen them being called "custom elements" then). That's what I do and I'm happy with the results.

"Web components" is really a collection of several independent specifications. Custom elements and shadow Dom are two of those, and I tend to agree that sticking with just custom elements will save a lot of headaches with the way things are now.

Re: How we use web components

#75
post #55

I've refreshed myself on web components, templates and shadow DOM, and I understand how each of them works, but I only see immediate benefits from templates. The rest seems a bit like abstraction for abstraction's sake and syntax sugar over existing capabilities. What am I missing, what's the elevator pitch for web-components and shadow DOM? Scoped styles seems to be something that's pushed with shadow DOM a lot, but…

> What am I missing, what's the elevator pitch for web-components and shadow DOM?

There's none except the oft-repeated "use the platform!" (as if other frameworks and libraries use something else, and not the platform).

Currently web components work, if:

- you have a large distributed team, and

- you need to have consistent elements and styling across many properties, and

- your components can be expressed as "leaf elements". That is, view-only elements. No forms, no state, only presenting some data.

Beyond that the elevator pitch is "for the past 10 years, and counting, we've been bravely trying to fix the ever-growing list of problems that web components introduced by simply being. And we're solving that by throwing more and more javascript at the problem".

A very non-exhaustive list: https://twitter.com/rich_harris/status/1198332398561353728?l...

And things like participation in forms? It's "solved" by adding Javascript: https://web.dev/more-capable-form-controls/

Which is ironic, given that the original pitch was "we're piling more and more into Javascript, and we shouldn't" https://fronteers.nl/congres/2011/sessions/web-components-an...:

--- start quote ---

I think we’re stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turing complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat.

Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you’d sent markup down the wire in order to get back to the same value that was going to be provided to you if you’d done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it’s stupid. Gmail does that because that’s how you can actually deliver the functionality of Gmail in a way that’s both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket.

--- end quote ---

Re: How we use web components

#76
post #38
post #27

Earlier quoted context omitted.

Super easy to incorporate with React. Just use react to pass attributes, like so: class App extends React.Component { render() { return ( ) } } In your webcomponent just make sure you listen to changes to that attribute like so: static get observedAttributes() { return ['custom-attribute'] } Then you can decide how the component changes whenever that attribute is updated by using the `attributeChangedCallback` functi…

Issues arise when trying to pass objects or add event listeners for custom events due to how React specifically handles this stuff. You often have to use refs

And even refs aren't enough if the custom element does its initial render asynchronously. I had to add mutation observers to some wrappers to avoid polling the ref.current.

Re: How we use web components

#77
post #55

I've refreshed myself on web components, templates and shadow DOM, and I understand how each of them works, but I only see immediate benefits from templates. The rest seems a bit like abstraction for abstraction's sake and syntax sugar over existing capabilities. What am I missing, what's the elevator pitch for web-components and shadow DOM? Scoped styles seems to be something that's pushed with shadow DOM a lot, but…

I'm wondering about the elevator pitch too. Honestly it seems like github went through all this trouble just because they don't want to commit to a framework like react. Still having a tough time seeing the benefits of web components.

I find it odd that people compare React and web-components a lot. Sure, superficially both have custom components. But why does that matter even?

To me React's value is JSX and ReactDOM. I actually use JSX+ReactDOM without the rest of React, using basic classes. Works great.

Re: How we use web components

#78
post #31

I have a very dumb question. I'm currently trying to implement web components into a pretty basic flask site, and I'm really having trouble. Does anyone know any resources about basic implementation that I can review? I was interested in Lit, and am try to bundle that, but it's not working at all, and I really feel like I'm missing something.

Check out https://open-wc.org/ Especially their code examples

thank you for this

Re: How we use web components

#79
post #35
post #31

I have a very dumb question. I'm currently trying to implement web components into a pretty basic flask site, and I'm really having trouble. Does anyone know any resources about basic implementation that I can review? I was interested in Lit, and am try to bundle that, but it's not working at all, and I really feel like I'm missing something.

You can get lit-specific advice on their Slack. The link is on their docs site

yes, thank you, it seems i'm not the only one asking this question there

Re: How we use web components

#80

I'm currently working on testing a UI with Selenium that uses Shadow DOM all over the place. It's hot garbage, and I have no idea why anybody thought this was a good idea. Something goes wrong in CI and you'd like to dump the DOM to figure out why? Too bad, the entire page is sitting inside a Shadow DOM, and you get to see an empty body tag and a timeout waiting for an element to appear. Want to click that button tha…

I don't really how you took a bug in Selenium and somehow turned it into an indictment of Shadow DOM.
Post reply on HN