Forem: Rob Levin

I Built 55+ CodePens for Every AgnosticUI Component. Here's What I Learned.

Rob Levin — Fri, 13 Mar 2026 15:47:00 +0000

AgnosticUI is a Web Components design system built on Lit, with React and Vue wrappers. The docs already had StackBlitz embeds proving the CLI install path works. But I wanted to prove the NPM package path too — and CodePen is the obvious place to do that. One click, zero setup, live and editable in the browser.

So I set a goal: every component gets a Pen.

The Setup

Each Pen imports directly from the AgnosticUI NPM package via CDN — no local install, no bundler, no CLI. If it works in the Pen, it works from NPM. That's the whole point.

The implementation side was straightforward. FrameworkExample.vue already had a CODEPEN_URLS map keyed by component name. Adding a new component was a two-step loop: create the Pen on codepen.io, add the URL to the map, commit.

Repeat 55 times.

What I Didn't Expect: The Bugs

Building these Pens wasn't just documentation work, it was dogfooding at scale. And dogfooding finds things that unit tests miss.

Two components had real bugs that only surfaced when running against the published NPM package in a clean, isolated environment. No monorepo context. No local file paths. Just the package as a consumer would actually use it.

Both bugs were squashed before the Pens went live.

That alone made the effort worth it. A test suite tells you if components work in isolation. A CodePen tells you if they work in the real world.

CodePen 2.0

These Pens were built on the newly launched CodePen 2.0. The team has rebuilt the platform significantly and it shows: the editor feels snappier, embeds are cleaner, and the overall experience is noticeably better than it was. Worth firing up a Pen just to see it if you haven't recently.

Where to Find Them

Every component page on the AgnosticUI docs now has a CodePen button on the React tab. Navigate to any component, click React, scroll to the examples section, and hit the button. Fork it, break it, adapt it.

55 Pens later, I can say with confidence the NPM package path is solid. That's the confidence check StackBlitz couldn't give us.

AgnosticUI is an open source Web Components design system. Contributions welcome.

Web Components: The "Missing Link" for Native Form Integration

Rob Levin — Thu, 12 Mar 2026 00:54:00 +0000

I recently realized that my Web Components in AgnosticUI were missing native form integration. Without Form-Associated Custom Elements (FACE), components often break standard browser behaviors like validation, resetting, and submission.

I just published a deep dive on Frontend Masters detailing how to use the ElementInternals interface to fix this. It’s the difference between a component that "looks" like a form field and one that actually is one in the eyes of the browser.

In this article, I cover:
✅ Why standard Web Components fail in forms.
✅ Implementing the ElementInternals interface.
✅ Handling validation, submission, and resets.
✅ Real-world implementation details from AgnosticUI.

Special thanks to Marc van Neerven for highlighting this gap!

Check out the full guide here:
https://frontendmasters.com/blog/form-associated-custom-elements-in-practice/

Why I’m still using @lit/react despite React 19’s Web Component support

Rob Levin — Thu, 05 Mar 2026 16:25:00 +0000

React 19 finally brought native Web Component support to the finish line, achieving a perfect score on Custom Elements Everywhere. However, after rewriting AgnosticUI with a unified Lit core, I discovered that "support" and "Developer Experience" are two very different things.

While you can use standard Custom Elements in React 19 now, I’m still opting for @lit/react for these three reasons:

The Event Mapping Tax: React's synthetic event system still feels clunky when listening to standard DOM events. @lit/react handles this mapping automatically.
Prop vs. Attribute DX: Passing complex data (objects/arrays) as properties rather than stringified attributes is still more ergonomic through a wrapper.
TypeScript Definitions: Getting high-quality Typings for a raw Custom Element inside JSX is still a manual chore that @lit/react automates.

Furthermore, moving to a "Source-First" architecture makes components more AI-readable, allowing LLMs to refactor code without the "black box" hallucinations common with traditional node_modules packages.

I recently published a full post-mortem on this migration over at Frontend Masters, where I dive into the other challenges like Shadow DOM accessibility, Form Participation, and styling with ::parts.

Read the full deep-dive here:
https://frontendmasters.com/blog/post-mortem-rewriting-agnosticui-with-lit-web-components/

Building a Scroll-Aware Blog Reader with AgnosticUI (React, Vue, Lit)

Rob Levin — Mon, 02 Mar 2026 14:00:00 +0000

Reading on the web has a UX problem. Most article layouts are just unstyled content with a nav stuck on top. The features that make reading feel good — a progress indicator, a back-to-top button that appears when you need it, inline search highlighting — are treated as nice-to-haves.

We built the Blog / Article Reader playbook to show what these features look like when they're implemented properly across all three major frameworks.

What's in the Playbook

ScrollProgress

A fixed top bar that grows as the user scrolls. Tells the reader exactly how far through the article they are without them having to think about it.

<ag-scroll-progress></ag-scroll-progress>

That's the entire implementation in the template. The component handles the scroll listener and progress calculation internally.

ScrollToButton

A floating button that appears in the bottom-right corner after the user scrolls past roughly 30% of the article. Clicking it smooth-scrolls back to the top. It's invisible when you don't need it — which is most of the time.

<ag-scroll-to-button threshold="0.3"></ag-scroll-to-button>

Mark — "Find in Article"

The ag-mark component highlights matching text inline. Pair it with ag-input for a search field and you've got a fully functional "Find in article" feature that works across paragraph breaks.

<ag-input label="Find in article" @input="updateSearch"></ag-input>
<!-- In article body: -->
<ag-mark :highlight="searchTerm">{{ articleBody }}</ag-mark>

Loader

The article simulates an async fetch with a loading state. ag-loader covers the content area until the fetch resolves — a realistic pattern for any data-driven article page.

Layout

The reading column is centered on desktop (~720px max) with generous side margins, shifts to a narrower centered column on tablet, and goes full-width single column on mobile. ag-aspect-ratio wraps the hero image to enforce 16:9 consistently across breakpoints.

AI-Assisted Customization

Like all AgnosticUI playbooks, PROMPT-3-FRAMEWORKS.md in the repo contains everything an LLM needs to generate or customize the implementation:

cd v2/playbooks/blog
claude
# > Please follow the instructions in PROMPT-3-FRAMEWORKS.md

Try asking: "Add a table of contents sidebar that highlights the active section as the user scrolls."

Try it live in StackBlitz or clone the repo:

AgnosticUI Onboarding Playbook

Rob Levin — Fri, 06 Feb 2026 16:00:00 +0000

AgnosticUI Onboarding Playbook

Multi-step onboarding wizard across React, Vue, and Lit.

What's Included

Three framework implementations (React, Vue, Lit)
Timeline progress indicator
Four-step flow: Welcome → Interests → Frequency → Complete
LLM prompts for AI-assisted customization
New components: SelectionButtonGroup and SelectionCardGroup

Components Used

ag-button - Navigation
ag-timeline - Progress tracking
ag-icon - Step indicators
ag-alert - Success messaging
ag-selection-card-group - Interest cards (new)
ag-selection-button-group - Frequency options (new)

AI Customization

Copy PROMPT-3-FRAMEWORKS.md into Claude or ChatGPT. Ask for modifications: "Add notification preferences step" or "Change the interest categories."

Framework-specific prompts available for Vue, React, and Lit.

Try It

Live examples and StackBlitz integrations: https://www.agnosticui.com/playbooks/onboarding.html

Source: https://github.com/AgnosticUI/agnosticui/tree/master/v2/playbooks/onboarding

New in AgnosticUI: SelectionButtonGroup & SelectionCardGroup

Rob Levin — Mon, 02 Feb 2026 16:03:00 +0000

SelectionButtonGroup

Button-styled radio/checkbox controls for compact selection UIs.

Perfect for:

Tag/filter selection
Multi-select pill buttons
Compact preference toggles
Form inputs where cards feel too heavy

Features:

3 sizes: sm, md, lg
3 shapes: rectangular, rounded, capsule
6 themes: primary, success, info, warning, error, monochrome
Full keyboard navigation (arrow keys!)
Accessible with proper ARIA semantics

<ag-selection-button-group type="radio" name="payment" shape="rounded">
  <ag-selection-button value="card">Credit Card</ag-selection-button>
  <ag-selection-button value="paypal">PayPal</ag-selection-button>
</ag-selection-button-group>

SelectionCardGroup

Card-based selection UI for rich content selection.

Perfect for:

Onboarding flows
Pricing tier selection
Feature preferences
User interests

Features:

Radio (single) & Checkbox (multiple) modes
Slotted content for rich cards
Responsive grid layout
CSS Parts API for deep customization
Same keyboard navigation & accessibility

<ag-selection-card-group type="checkbox" name="features">
  <ag-selection-card value="analytics" label="Analytics">
    <div>Analytics</div>
    <p>Track user behavior</p>
  </ag-selection-card>
</ag-selection-card-group>

Both Components Support:

☐ React, Vue, Lit/Web Components, Svelte
☐ Theme variants for semantic states

☐ Controlled & uncontrolled modes
☐ Full TypeScript support
☐ Zero runtime dependencies

Discovery Process

These components emerged organically while building our Onboarding Playbook (think Login Playbook but for user onboarding flows). When you build real UI patterns, the component needs reveal themselves!

Onboarding Playbook drops later this week 🎉

Documentation

AgnosticUI remains committed to truly framework-agnostic components that work identically across all major frameworks.

webdev #javascript #react #vue #svelte #webcomponents #opensource

AI UI Without the Hallucinations

Rob Levin — Tue, 27 Jan 2026 19:50:25 +0000

I care about design system adherence, technical flexibility, and clean code — so I wanted to see if I could get the LLM to cooperate and use AgnosticUI to build a bespoke login form.

It took a few attempts, but I got there. The AI generates the login without hallucination, follows real breakpoints, and sticks to design-system constraints.

Same spec, multiple frameworks. Different fonts and branding to show it's customizable.

The Login Playbook and prompts are public in the AgnosticUI docs — useful if you're experimenting with AI + design systems and care about repeatable output.

https://www.agnosticui.com/playbooks/login.html

There you'll also find live StackBlitz examples and a link to the markdown prompts on GitHub.

Prompt-Driven UI: Building Production-Ready Login Pages with AgnosticUI & AI

Rob Levin — Wed, 21 Jan 2026 22:49:37 +0000

Imagine generating a complete, production-ready UI across React, Vue, and Lit with a single AI prompt—eliminating framework lock-in and design drift for good. Read on…

Over the past week, I’ve been heads-down building AgnosticUI’s first Login Playbook. It’s an AI-optimized template designed to leverage our framework-agnostic architecture to spit out fully responsive login layouts in seconds. Whether you’re leaning into a high-speed "vibe coding" session or executing a disciplined design system rollout, this playbook gives you a production-ready foundation that bridges the gap between raw AI generation and hand-crafted code.

I can already hear the sighs: "Great, another cookie-cutter login page, dude." Right then. Well, it IS just a starter template—the whole point is for you to tear it apart and make it yours!

Most AI-generated UI today results in what I'd call "AI Slop": a mess of React, Shadcn, and Tailwind that gets shoved down your throat whether you want it or not. Am I the only one who actually wants a choice in their tech stack? I certainly hope not!

In any event, what you get is cookie-cutter generic output that has a "me too" look and doesn't establish any semblance of design system worthy code. And worse, as you continue to add pages: Styling is inconsistent across prompts. Accessibility is ignored. And you're locked into one framework. Always. React.

Well, maybe you're more of a nitpicky dev like me. Maybe you'd like to have some sort of component library awareness, design token based CSS custom properties and design system constraints, cross-framework compatibility from day one, and at minimum passing accessibility.

Enter the Playbook Pattern

A Playbook is a structured prompt template that gives an LLM everything it needs to generate consistent, high-quality UI. It really shouldn't matter if you use Sonnet/Opus 4.5, Gemini, etc., within reason.

Here's what goes in:

Component Inventory - Available components and their props
Visual Hierarchy - Layout structure and element order
Responsive Breakpoints - Mobile, tablet, desktop behaviors
Styling Constraints - Tokens, variants, and spacing rules
Framework Scaffolding - How to structure the output code

The Login Playbook Structure

# Component Hierarchy
1. **Logo** - Brand identifier (The boilerplate has Ag with blue 'A' because that's AgnosticUI's demo. Of course you will replace this!)
2. **Title** - "Welcome back!" heading
3. **Email Field** - Input with mail icon addon
4. **Password Field** - Input with lock icon addon
5. **Remember/Forgot Row** - Checkbox + link
6. **Primary CTA** - Full-width login button
7. **Social Auth** - Facebook and Google buttons

_All the above can be swapped e.g. you can remove Facebook for Apple or whatever._

**Layout Constraints:**
- Mobile: Single column, full width
- Tablet: Centered card (400px max)
- Desktop: 40/60 split (form left, hero image right)

**Component Variants:**
- Button (Login): `variant="monochrome" shape="rounded"`
- Button (Social): `bordered shape="rounded"`
- Input: `rounded` with left addon slots

Again, this is a starter template. You can update the core design tokens for a radically different theme, use a different AgnosticUI Button variant, and obviously replace the hero image. OMG, please replace that!

The Generated Code

React Implementation

import React, { useState } from 'react';
import { Mail, Lock } from 'lucide-react';
import { ReactButton } from 'agnosticui-core/button/react';
import { ReactInput } from 'agnosticui-core/input/react';
import { ReactCheckbox } from 'agnosticui-core/checkbox/react';
import { ReactLink } from 'agnosticui-core/link/react';

export function LoginForm() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [remember, setRemember] = useState(false);

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    console.log({ email, password, remember });
  };

  return (
    <form onSubmit={handleSubmit} className="login-form">
      <div className="logo">Ag</div>
      <h1>Welcome back!</h1>

      <ReactInput
        label="Email"
        type="email"
        placeholder="Enter your email"
        value={email}
        onInput={(e) => setEmail(e.target.value)}
        rounded
        required
      >
        <Mail 
          slot="addon-left" 
          size={18} 
          style={{ color: 'var(--ag-text-secondary)' }} 
        />
      </ReactInput>

      <ReactInput
        label="Password"
        type="password"
        placeholder="Enter your password"
        value={password}
        onInput={(e) => setPassword(e.target.value)}
        rounded
        required
      >
        <Lock 
          slot="addon-left" 
          size={18}
          style={{ color: 'var(--ag-text-secondary)' }} 
        />
      </ReactInput>

      <div className="remember-forgot">
        <ReactCheckbox
          checked={remember}
          onChange={(e) => setRemember(e.target.checked)}
          label="Remember me"
        />
        <ReactLink href="#forgot">Forgot password</ReactLink>
      </div>

      <ReactButton
        type="submit"
        variant="monochrome"
        shape="rounded"
        isFullWidth
      >
        Login
      </ReactButton>

      <div className="divider">or</div>

      <ReactButton 
        bordered 
        shape="rounded" 
        isFullWidth
        onClick={() => console.log('Facebook login')}
      >
        <Facebook size={18} /> Facebook
      </ReactButton>

      <ReactButton 
        bordered 
        shape="rounded" 
        isFullWidth
        onClick={() => console.log('Google login')}
      >
        <img src="/google-icon.svg" alt="" /> Google
      </ReactButton>

      <div className="signup-prompt">
        Don't have an account? <ReactLink href="#signup">Sign up</ReactLink>
      </div>
    </form>
  );
}

The Responsive Layout

.login-container {
  min-height: 100vh;
  display: flex;
  align-items: center;
  justify-content: center;
  padding: var(--ag-space-4);
}

/* Mobile: Full width, single column */
.login-form {
  width: 100%;
  max-width: 400px;
  display: flex;
  flex-direction: column;
  gap: var(--ag-space-4);
}

/* Tablet: Centered card */
@media (min-width: 768px) {
  .login-container {
    background: var(--ag-bg-secondary);
  }

  .login-form {
    padding: var(--ag-space-8);
    background: var(--ag-bg-primary);
    border-radius: var(--ag-radius-lg);
    box-shadow: var(--ag-elevation-3);
  }
}

/* Desktop: Split layout with hero image */
@media (min-width: 1200px) {
  .login-container {
    display: grid;
    grid-template-columns: 2fr 3fr; /* 40% form / 60% hero */
    padding: 0;
  }

  .login-column-left {
    display: flex;
    align-items: center;
    justify-content: center;
    padding: var(--ag-space-8);
  }

  .login-column-right {
    background: url('/hero-mountain.jpg') center/cover;
    min-height: 100vh;
  }
}

.logo {
  font-size: 2rem;
  font-weight: 600;
  margin-bottom: var(--ag-space-2);
}

.logo::first-letter {
  color: var(--ag-primary);
}

.divider {
  display: flex;
  align-items: center;
  gap: var(--ag-space-4);
  color: var(--ag-text-secondary);
  text-align: center;
}

.divider::before,
.divider::after {
  content: '';
  flex: 1;
  border-top: 1px solid var(--ag-border-color);
}

.remember-forgot {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

.signup-prompt {
  text-align: center;
  color: var(--ag-text-secondary);
}

Why This Works

Framework-Agnostic Core

The same prompt generates Vue and Lit versions because AgnosticUI components are built on Web Components (Lit) with framework wrappers:

// The core logic exists once in Lit
export class AgnosticInput extends LitElement {
  @property({ type: String }) label = '';
  @property({ type: String }) type = 'text';
  @property({ type: Boolean, reflect: true }) rounded = false;

  render() {
    return html`
      <div class="input-wrapper">
        <label>${this.label}</label>
        <div class="input-container">
          <slot name="addon-left"></slot>
          <input type="${this.type}" />
          <slot name="addon-right"></slot>
        </div>
      </div>
    `;
  }
}

// React wrapper is just mapping
export const ReactInput = createComponent({
  tagName: 'ag-input',
  elementClass: AgnosticInput,
  react: React,
  events: {
    onInput: 'input',
    onChange: 'change',
  },
});

Design Token Integration

The CSS uses AgnosticUI's token system, built with Style Dictionary:

// tokens/spacing.json
{
  "space": {
    "4": { "value": "1rem" },
    "8": { "value": "2rem" }
  }
}

Generated CSS:

:where(html) {
  --ag-space-4: 1rem;
  --ag-space-8: 2rem;
}

Have a look at the theme-registry source code to get a feel for how the design tokens are set up, or check out the resulting styles.

Consistent spacing across all generated layouts.

Accessibility Built-In

Because we're using semantic components with proper ARIA, form labels are properly associated, focus management works, keyboard navigation is handled, and screen readers get the context they need.

No extra prompt engineering required for a11y.

The Developer Experience

Copy the PROMPT.md into Claude, ChatGPT, or your preferred LLM with instructions to create a login page.

The LLM generates:

LoginForm.tsx (React)
LoginForm.vue (Vue)
LoginForm.lit.ts (Lit)

All using the same components, all maintaining design consistency. Obviously, you're free to delete the generated framework components you don't want (but it IS neat to see them all produced, no?). Or, you could use the Lit-based LoginForm.lit.ts one for Svelte, Solid, Preact, Angular, etc., with a bit of tweaking since, ultimately, that's just web components.

Customize Without Breaking Things

Because it's using a real component library, you can swap button variants (primary, secondary, monochrome), adjust spacing with tokens (--ag-space-*), add new fields using the same Input component, and change responsive breakpoints.

The AI gave you a starting point. Your design system keeps you consistent.

Beyond Login - The Playbook Strategy

We're building playbooks for common UI patterns:

Current Playbooks:

Upcoming playbook ideas (would love your feedback on which ones we should tackle):

Dashboard layouts
E-commerce checkout
Settings panels

Each playbook will include component mapping, responsive strategies, and accessibility requirements with a disclaimer that these will be "dumb UI layouts".

Screenshots

Mobile (375×812): Vertical stack, thumb-friendly buttons
Tablet (768×1024): Centered card with elevation
Desktop (1440×1080): Split hero layout with 40/60 grid

View Screenshots on GitHub

AI + Design Systems

AI code generation becomes useful when constrained by a solid design system. It's early, but I've started building a Figma and used it to build the Login page template: https://github.com/AgnosticUI/agnosticui/blob/master/v2/graphics/AgnosticUI-2.fig

There are only 5 components so far, but given demand and/or community support the hope is that this Figma will eventually grow to reflect the 50+ components available in the UI kit.

Without constraints: Every prompt gives different styling, accessibility is an afterthought, and framework migration means rewriting from scratch.

With AgnosticUI Playbooks: Consistent design language, built-in accessibility, framework portability, and production-ready output.

Try it yourself:

# Get started in under 2 minutes
npx agnosticui-cli init

Explore the Login Playbook:
https://github.com/AgnosticUI/agnosticui/tree/master/v2/playbooks/login

What UI patterns should we build playbooks for next? Drop a comment below.

About AgnosticUI

AgnosticUI is an open-source component library that works across React, Vue, Svelte, Angular, and vanilla JavaScript. Built on Web Components with framework wrappers, it lets you write once and deploy everywhere.

GitHub: https://github.com/AgnosticUI/agnosticui
Docs: https://www.agnosticui.com

Fixing Focus Management in Nested Web Components

Rob Levin — Mon, 06 Oct 2025 00:33:31 +0000

The Problem

While building a drawer component system, I encountered a peculiar focus management bug. When opening a drawer, the initial focus was supposed to land on the Close button. Instead, the ag-drawer element itself was receiving focus, and our focus detection utility was returning an empty arrayeven though the Close button was clearly visible and focusable.

The Architecture

Our drawer component has an interesting architecture:

<ag-drawer>
  <p>Drawer content</p>
  <ag-button>Close</ag-button>
</ag-drawer>

Internally, ag-drawer renders an ag-dialog in its Shadow DOM:

// ag-drawer's shadow DOM
render() {
  return html`
    <ag-dialog
      .open=${this.open}
      .heading=${this.heading}
      // ... other props
    >
      <slot></slot>
    </ag-dialog>
  `;
}

So the component hierarchy looks like this:

ag-drawer (light DOM: <ag-button>Close</ag-button>)
   shadow root
       ag-dialog
           shadow root
               <slot> (projects ag-drawer's light DOM)

The First Bug: Custom Element Visibility Detection

Our getFocusableElements utility was filtering out the ag-button because of this check:

// Exclude elements that are not visible
if (el.offsetParent === null && window.getComputedStyle(el).position !== 'fixed') {
  return false;
}

Custom elements can have offsetParent === null even when visible, especially:

During render cycles
After parent transitions
In Shadow DOM contexts

Fix: Skip the offsetParent check for custom elements:

const isCustomElement = el.tagName.includes('-');
if (!isCustomElement && el.offsetParent === null && window.getComputedStyle(el).position !== 'fixed') {
  return false;
}

The Second Bug: Wrong Light DOM Search Scope

Even after fixing the custom element detection, the Close button still wasn't found. The issue? We were searching the wrong light DOM container.

ag-dialog was calling:

getFocusableElements(this.shadowRoot, this) // 'this' is ag-dialog

But the slotted content (Close button) lives in ag-drawer's light DOM, not ag-dialog's. ag-dialog's light DOM is emptyit's just a slot that projects content from its parent host.

Fix: Find the parent host element when inside a shadow root:

private _setInitialFocus() {
  // For drawers, the slotted content is in the parent ag-drawer's light DOM
  const lightDomContainer = (this.getRootNode() as ShadowRoot).host as HTMLElement || this;
  const focusableElements = getFocusableElements(this.shadowRoot, lightDomContainer);

  if (focusableElements.length > 0) {
    focusableElements[0].focus();
  }
}

Now ag-dialog correctly searches ag-drawer's light DOM for focusable elements.

Key Takeaways

Custom elements need special visibility handling - Standard DOM visibility checks like offsetParent === null can incorrectly filter out custom elements.
Understand your Shadow DOM hierarchy - When searching for slotted content, you need to search the correct host's light DOM, not the component doing the rendering.
getRootNode().host is your friend - It helps you traverse up the Shadow DOM tree to find parent custom elements.

The Result

Focus management now works correctly:

Close button receives initial focus when drawer opens
Focus trap properly cycles through all focusable elements
Custom elements are correctly identified as focusable

This was a great reminder that Shadow DOM creates encapsulation boundaries that require careful thought when implementing cross-boundary features like focus management.

Let's Play with Lit

Rob Levin — Sun, 05 Oct 2025 00:34:19 +0000

1. Setting Up Lit

Probably the most straight forward way to start using Lit is to set it up using vite:

npm create vite@latest my-lit-app -- --template lit-ts

Then you'll be able to cd into the directory and just follow the direction. Alternatively, you can use a CDN in an HTML file:

<script src="https://cdn.skypack.dev/lit"></script>

Lit is a modern framework for creating web components with a minimal API and optimal performance. It handles efficient rendering and easy reactivity for component data.

2. Creating a Simple Web Component

Lit works by extending the LitElement base class. Here's a basic component:

import { LitElement, html, css } from 'lit';

class MyComponent extends LitElement {
  static styles = css`
    :host {
      display: block;
      color: blue;
    }
  `;

  render() {
    return html`<p>Hello, Lit!</p>`;
  }
}

customElements.define('my-component', MyComponent);

LitElement: The base class for component logic, lifecycle hooks, reactivity, and rendering.
html: A tagged template literal for writing HTML and updating DOM elements.
css: A tagged template literal for defining scoped component styles.

Why `LitElement`?

LitElement provides reactive data binding and an efficient rendering engine. When a component's properties change, it updates only the dynamic parts of the DOM, which minimizes unnecessary re-renders for better performance. This process is known as DOM Diffing.

3. Using Reactive Properties

In Lit, you declare reactive properties via the static properties getter to trigger re-renders when their values change.

static properties = {
  place: { type: String }
};

constructor() {
  super();
  this.place= 'World';
}

render() {
  return html`<p>Hello, ${this.place}!</p>`;
}

Reactivity: Lit's reactivity engine observes changes to properties (like place), and changes and automatically triggers a re-render.

4. Handling Events

Event handling is done in Lit using a familiar @event syntax. For example, to handle clicks:

render() {
  return html`<button @click="${this._handleClick}">Click me</button>`;
}

_handleClick() {
  console.log('The button was clicked...');
}

Here, @click binds the button's click event to the _handleClick method.

5. Styling Components

In Lit, styling is done via the css tagged template literal and scoped to the component. This means styles won’t inadvertantly leak.

static styles = css`
  :host {
    display: block;
    color: blue;
  }
  button {
    background: green;
  }
`;

6. Slots

You can create custom components that allow for content projection using the <slot> element. This lets users pass their content into the component.

render() {
  return html`<slot></slot>`;
}

7. Lifecycle Methods

Lit provides lifecycle methods that give you hooks into the component’s life cycle, such as connectedCallback(), disconnectedCallback(), and updated().

Example:

connectedCallback() {
  super.connectedCallback();
  console.log('Component was connected to the DOM!');
}

8. Using Directives for Dynamic Behavior

Lit provides directives like ifDefined for conditional rendering and repeat for iterating over lists. This makes it easy to handle dynamic content.

Example:

import { ifDefined } from 'lit/directives/if-defined.js';

render() {
  return html`<div>${ifDefined(this.someValue ? this.someValue : undefined)}</div>`;
}

Why directives?

Directives can provide advanced capabilities perhaps similar to hooks in React, but are a topic we'll save for longer article in the future.

How You Might Create a Simplified UI Component for AgnosticUI Framework

I'm rewriting my UI library AgnosticUI in Lit for the core primitive components. I'll write another article on "the whys" but for now, let's take a simplified version of one of my components to explore how you might use Lit in building a component library.

The AgnosticUI Button is a rich, accessible button component with a variety of states and styles, and it uses custom design tokens for theming. Here, I've simplified it so hopefully you can see some of the possibilities of what Lit has to offer for such an endeavor (yes, I like to use words like endeavor—and that em dash was me not AI):

1. Component Setup

The AgButton class would extend LitElement and define properties for all the button’s attributes (variant, size, shape, disabled, etc.). For reactivity, each of these would be defined as a @property.

In Lit, the css tagged template literal is perfect for handling those dynamic styles using design tokens. Again, we'll simplify the button and show how variant and size styles could be written. You'll need to imagine that you already have already setup some CSS custom properties:

export class AgButton extends LitElement {
  static styles = css`
    /* :host refers to the AgButton or ag-button itself */
    :host {
      display: inline-flex;
      justify-content: center;
      align-items: center;
    }
    button {
      background: var(--ag-background-tertiary);
      color: var(--ag-text-color);
    }

    /* <ag-button variant="primary">My Button</ag-button> */
    :host([variant="primary"]) button {
      background: var(--ag-primary);
      color: white;
    }

    /* <ag-button size="md">My Button</ag-button> */
    :host([size="md"]) button {
      padding: var(--ag-space-2);
      font-size: var(--ag-font-size-base);
    }
  `;

3. Conditional Styling

The AgButton has various states like loading, pressed, and disabled. You can handle these states dynamically in Lit using the render() method, where you can bind properties to aria-* attributes for accessibility and manage class or style changes for different states.

render() {
  return html`
    <button 
      ?disabled=${this.disabled || this.loading}
      aria-pressed=${this.toggle ? String(this.pressed) : undefined}
      aria-label=${ifDefined(this.ariaLabel)}
      @click=${this._handleClick}
    >
      <slot></slot>
    </button>
  `;
}

4. Event Handling & Interaction

For handling the click, focus, or blur events, you can use Lit’s event handling syntax (@click, @focus, etc.) and pass custom events like we've shown earlier.

For example, toggling the pressed state could dispatch a custom toggle event:

_handleClick() {
  if (this.toggle) {
    this.pressed = !this.pressed;
    this.dispatchEvent(new CustomEvent('toggle', { detail: { pressed: this.pressed }, bubbles: true, composed: true }));
  }
}

Conclusion

Using Lit to build web components provides a rich set of reactive properties, scoped styles, and declarative event handling, and minimizes boilerplate. This, in turn, improves maintainability and dUX while also keeping your component behaviors predictable and consistent. As I mentioned, I'm currently rebuilding AgnosticUI atop of Lit, so you're welcome have a look as I "build in public" in the upcoming weeks. Here's the feature branch for v2.

I was on The Function Call podcast tonight!

Rob Levin — Fri, 18 Mar 2022 02:04:26 +0000

I was in full on technogeekery mode tonight getting to talk all about my UI component library AgnosticUI on The Function Call podcast!

https://youtu.be/UoHamm66UBA

Theming AgnosticUI with open-props is easy peasy!

Rob Levin — Wed, 16 Mar 2022 17:57:09 +0000

agnostic-svelte + open-props === easy theming 🎨

My blog uses svelte-kit and so I've been testing my AgnosticUI Svelte package (agnostic-svelte on NPM) there. I'm quite happy to report that Vest and open-props both work quite well with AgnosticUI!

Vest is a declarative form validation library that is inspired by unit testing libraries like Mocha or Jest.

You can see my experiments with integrating with Vest here.

open-props Supercharged CSS variables that give you a nice head-start on your CSS custom properties and/or theming efforts.

You can see my experiments with open-props here (just click the Theming tab once you get there and then select from the theme radio buttons)

And if that's not enough, I did some experiments with CSS Grid too! All the examples have links to the GitHub source code in case you wanna snag a Grid layout:

The layout experiments provided are:

Simple Header & Footer
Sidenav
Sidenav Full Height
Holygrail
Holy Sidbars (basically holy grail but the sidebars on both side extent full height)

I hope y'all can go have a look at these experiments and find them useful!

Forem: Rob Levin

I Built 55+ CodePens for Every AgnosticUI Component. Here's What I Learned.

The Setup

What I Didn't Expect: The Bugs

CodePen 2.0

Where to Find Them

Web Components: The "Missing Link" for Native Form Integration

Why I’m still using @lit/react despite React 19’s Web Component support

Building a Scroll-Aware Blog Reader with AgnosticUI (React, Vue, Lit)

What's in the Playbook

ScrollProgress

ScrollToButton

Mark — "Find in Article"

Loader

Layout

AI-Assisted Customization

AgnosticUI Onboarding Playbook

AgnosticUI Onboarding Playbook

What's Included

Components Used

AI Customization

Try It

New in AgnosticUI: SelectionButtonGroup & SelectionCardGroup

SelectionButtonGroup

SelectionCardGroup

Both Components Support:

Discovery Process

Documentation

webdev #javascript #react #vue #svelte #webcomponents #opensource

AI UI Without the Hallucinations

Prompt-Driven UI: Building Production-Ready Login Pages with AgnosticUI & AI

Enter the Playbook Pattern

The Login Playbook Structure

The Generated Code

React Implementation

The Responsive Layout

Why This Works

Framework-Agnostic Core

Design Token Integration

Accessibility Built-In

The Developer Experience

Customize Without Breaking Things

Beyond Login - The Playbook Strategy

Screenshots

AI + Design Systems

About AgnosticUI

Fixing Focus Management in Nested Web Components

The Problem

The Architecture

The First Bug: Custom Element Visibility Detection

The Second Bug: Wrong Light DOM Search Scope

Key Takeaways

The Result

Let's Play with Lit

1. Setting Up Lit

2. Creating a Simple Web Component

Why LitElement?

3. Using Reactive Properties

4. Handling Events

5. Styling Components

6. Slots

7. Lifecycle Methods

8. Using Directives for Dynamic Behavior

Why directives?

How You Might Create a Simplified UI Component for AgnosticUI Framework

1. Component Setup

3. Conditional Styling

4. Event Handling & Interaction

Conclusion

I was on The Function Call podcast tonight!

Theming AgnosticUI with open-props is easy peasy!

agnostic-svelte + open-props === easy theming 🎨

Why `LitElement`?