Lattice UI Docs Components

Components

Decision-oriented package documentation for Lattice UI components and foundations.

On this page

These pages are organized around integration decisions rather than package names. Each package page explains what the component is for, how ownership and state behave, which parts of the API affect composition, and which cautions should be reviewed before using it in a production screen.

The package surface is not flat in maturity. This docs set treats the stable direction as the default path, while clearly calling out feature-limited packages like select and slider when their constraints matter to integration decisions.

Registry-backed component surface in the current source repo: 26 packages.

Decision Guides

Choosing controls

Use side-by-side comparisons before you pick a selection or overlay primitive.

  • Choosing Controls

    Compare Select vs Combobox vs Radio Group, Dialog vs Popover, and Switch vs Checkbox.

Implementation pitfalls

Review the failure modes that show up most often once real app state and overlays are involved.

Start from foundations

Establish theme, density, layout, and overlay rules before composing interaction-heavy UI.

  • Style

    Theme tokens, recipes, primitives, and styling composition rules.

  • System

    Providers, layout primitives, surfaces, and app-level UI behavior.

  • Layer

    Portal ownership, outside dismissal, and the shared stacking model.

  • Motion

    Presence, response, feedback, and reduced-motion policy.

See one assembled screen

Use one practical flow to understand how several packages work together in context.

  • Build a Settings Dialog

    See Style, System, Text Field, Select, and Dialog assembled into one real screen.

  • Quick Start

    Review the current create, init, add, remove, doctor, and upgrade workflow.

Browse by Task

App foundations

Use these first when a screen needs stable structure, focus rules, or shared infrastructure.

Collect input

Use these when the screen owns entry, toggles, progress, or validation-heavy interaction.

Choose from options

Use these when the screen needs single choice, grouped selection, or progressive disclosure.

Open layered surfaces

Use these when content leaves normal layout flow or needs anchored, dismissible overlays.

Compose dense surfaces

Use these when the screen needs avatars, constrained panes, or scrollable content regions.

How to Read a Package Page

  • Read What It Is For first to confirm the package matches the screen problem you actually have.
  • Use the generated install/export/provider metadata to confirm the public package surface before wiring it into an app.
  • Use State Model to understand controlled ownership, focus movement, and overlay behavior before implementation starts.
  • Read Cautions / Limits before committing the package to a larger workflow.
  • Treat Complete TSX Example as the quickest path to a working baseline, then branch into the comparison and pitfalls guides when you need sharper decisions.