Lit.dev

Testing Web Components

While any test framework can work, it’s better to test web components in a browser environment because that’s where they’ll be used. Node-based frameworks would require too much shimming of DOM calls that’d make the tests unrepresentative. and are good options for browser-based testing.

is powered by ES-build, and so is the client-side of the app; let’s go down this path and see where it leads. CommonJS modules don’t work in the browser . Earlier on , using ESM on the server turned out difficult. Hopefully, that doesn’t me bite back now.

More than once, I’ve been surprised by a web component either showing data that should no longer be there, or not showing data that should be there. This page aims to reason through such cases for a better mental model of web components.

Rendering Lists

Both <search-bar> and <search-results> need to render a collection of N items. offers two options: looping, or using the repeat(items, keyFunction, itemTemplate) directive.

const cards = html`
  ${cards.map(
    (card) => html`<div><input type="checkbox">${card.title}</div>`
  )}
`;

const template2 = html`
  ${repeat(
    cards, (card) => card.id
    (card) => html`<div><input type="checkbox">${card.id}</div>`
  )}
`;

When performing updates, repeat moves DOM nodes, while map reuses DOM nodes. This is also beneficial when there is some part of the node that isn’t controlled by a template expression because repeat will keep that state, e.g, in the example above, the checked property. If none of these apply, then map or loops can be used over repeat.

Mixins

A mix-in is an abstract subclass. This technique is especially useful in languages where a class can only have a single superclass.

const calculatorMixin = (Base) =>
  class extends Base {
    calc() {}
  };

const randomizerMixin = (Base) =>
  class extends Base {
    randomize() {}
  };

class Foo {}
class Bar extends calculatorMixin(randomizerMixin(Foo)) {}

Sharing Code with /browse

Components initially created for the /browse page are useful in /home as well.

The CardsViewingPage Interface

This functionality can be shared between the two pages:

Context

How can I reuse code in these user experiences?

<search-bar>

Currently, this is rendered by search_bar_dropdown.ejs, a partial that that is included in both /home and /browse. The fact that there it has JS, no server-delivered content, and has CSS makes it a good candidate for a web component. Revving up search-bar.ts.