How we use web components • Hacker News Board

Re: How we use web components

#81

Post by kazoomonger » Wed, May 05, 2021, 9:38 PM UTC

mhoad wrote: post #80

kazoomonger wrote: post #52

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.

It's not just Selenium, it's anything that has to interact with Shadow DOM. If you want to use pure JS to click the button in my above example, you can't just write this:

    document.querySelector("#foo").click()

You have to write something like this:

    document.querySelector("#nested-1").shadowRoot.querySelector("#nested-2").shadowRoot.querySelector("#foo").click()

It's not just the length of the query (which can get stupidly long), it's that you have to know and care about the overall structure of the document and where the button sits in it. I just want to click the damn button. It has a nice, easy-to-find ID attached to it, why does that have to be so hard?

Also, it's not a Selenium bug that you can't dump the entire DOM when Shadow DOM gets involved. That's by design; Selenium just allows you to call `innerHTML` or similar, and if the tag is using Shadow DOM because someone else thought it was a great idea to make the whole page a Web Component then you're SOL and you'll just get ``. Have fun debugging that.

The worst part about all this bad design is that it wasn't even necessary. Are you worried about a bad CSS rule from some fancy component causing havoc with the rest of your page? There should exist something as simple as `...`. Have those rules scoped to that div element and you're done, problem solved. Worried about some component's JS causing havoc? Same thing, `...`. All JS is automatically scoped to that div element. That would have been far better than the brain-dead approach of Shadow DOM.

Re: How we use web components

#82

Post by kazoomonger » Wed, May 05, 2021, 9:46 PM UTC

tmcneal wrote: post #72

kazoomonger wrote: post #52

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://r…

That looks cool, but from what I can tell, not really something I can use. All of the Selenium testing I'm doing is accessed via localhost, often on bare metal. None of it's available via the internet, which it looks like is required by your service.

Re: How we use web components

#83

Post by claytongulick » Wed, May 05, 2021, 10:58 PM UTC

laurent123456 wrote: post #39

claytongulick wrote: post #5

I do pretty much everything with Web Components these days. It's so nice to be able to pick things I need from different frameworks, like Ionic, vaadin, Shoelace, etc... and they all just work together. I tend to implement vanilla web components, I enjoy managing the life cycle and don't find it particularly burdensome. Of course. Lit-html is a big reason why that's easy to do. I use it for rendering. I generally avo…

I don't know if it's on purpose, but ApplicationState is a lot like Redux, except the action dispatching mechanism has been replaced with setting state properties directly. I'd still prefer the dispatch mechanism since it means you can have additional, reusable logic in the reducer.

Its design was specifically intended to avoid the extra code involved in dispatching.

There are also some other goodies in there like aliasing that I enjoy.

Re: How we use web components

#84

Post by patates » Thu, May 06, 2021, 8:54 AM UTC

deergomoo wrote: post #65

patates wrote: post #62

Earlier quoted context omitted.

You can link to your main css from within the component. Browsers are smart enough to use the cached css file.

Interesting! I had not considered that. I don't suppose you know if there's any performance impact there—e.g. even if it's not downloading it, is there overhead from processing the file once per component?

I'm not sure, but I haven't had any performance problems (including some performance score tests), even in larger projects.