Elf M. Sternberg

Full Stack Web Developer

Where one teaches, two learn.

Tag: #lit-element

To all tags

Working with Claude LLM: Zero for Two This Week

I asked Claude, one of the AIs supposedly "good for programming," to help me out with two tasks today. The first was "I have a page with a collection of cards on it. The cards are web components. Each component has a button inside its shadowDOM, and the label on each button is different. Using WebdriverIO, I want to find the card that has a button with a specific label."

It failed utterly. Then it failed again.

Code snippet: Using Awk to Find Specific Clauses in HTML

If you've ever needed to hunt through a massive HTML project for a specific, repetitive clause, there aren't a lot of tool that are really that helpful. I'm sure there are some tools better suited to it, but I found a recipe for gawk that I like.

Tip: Delete Lit's hidden cache when using WebdriverIO to test Lit-Element components.

I recently had a horrible experience where I could not get Lit to run the same test twice using the WebdriverIO Component Testing Guidelines for Lit.

The test is simple: Before each test, render the component, click on it, see if its internal state is what I expect, and then remove the component at the end of the test. I expected that if I ran the exact same test twice, it would work (or fail) twice.

It turns out Lit is being passive-aggressive about caching what you've done, won't re-render cached content preferring to re-connect it instead, and won't help you figure out that it doesn't exist anymore and can't be re-connected.

Web Components: A Cautionary Tale about the Shadow DOM and innerHTML

After six years of writing React professionally, I have decided that I really prefer Web Components to React, Angular, Vue, or any of their ilk. Web Components are the browser's native model for defining components; they don't need huge libraries to "route around" deficiencies in the browser nor do they need special context or event types; they just use the browser's own event dispatcher, and context is managed by putting stopPropogation on the context handler's DOM Node.

I recently spent some time trying to port my old jQuery/Backbone demo, Fridgemagnets, to a Web Component model.

I started out by using Lit-Element. Lit is a very small toolkit from Google which creates a bundle of only 5KB, much smaller than React's 40. I had good reasons: due to the history of Web Components, the API is awkward with very long method names and an annoyingly complex dance to convert text to a DOM Node. Lit streamlines a lot of that, but it also adds something that I usually find annoying: all your events that cause a state change in a component are batched and propagated at once, debounced to prevent refresh pauses. Lit wants to make web components "reactive," so your state is stored in monitored attributes.

For the most part, I can live with that. But in the conversion to FridgeMagnets, I hit a headache.