Component libraryChoose · Compose · Refine

Components for flexible Preact interfaces

Explore 68 components for forms, navigation, feedback and content. Start with one useful interaction, read its examples and API, then combine the pieces into a working screen. Kamod’s Preact components share theme tokens and familiar patterns while your application owns the data, routes and service callbacks.

Use the index below to find a control, or follow the practical guidance to choose components, connect state and accessible labels, and adapt the result with Tailwind CSS. New to the setup? Begin with the installation guide and global CSS. For a complete starting layout, explore blocks built from the same @kamod-ch/ui primitives.

In this guide 6 sections

Find your next component

Browse the complete library. Each entry opens its installation documentation, with examples and API references available from that page. Check the props and supported composition before copying an example; similarly named controls can serve different interaction patterns.

Start small: render the simplest example in your app before connecting services or changing its appearance. Keep imports on the public @kamod-ch/ui API and follow your project’s existing conventions for files and state.

Choose the right building blocks

Start with the user’s task, then choose the control. A familiar visual treatment is useful only when the interaction underneath matches what people expect. Pick the smallest component that handles the job, open its examples, and read its API before adding a custom abstraction. The links below are starting points, not a required list of dependencies.

Prefer existing keyboard, focus and overlay behavior over rebuilding it with generic elements. Your application still supplies the data, routing, validation rules and service callbacks. Kamod components give those decisions a consistent interface.

What you need	Start here	Make the choice deliberate
Trigger an action	`Button` · `Button Group`	Use a button for an action and a link for navigation. Name the result: Save changes is clearer than Submit outside a form.
Collect a value	`Input` · `Field` · `Select`	Start with a visible label and helpful instructions. Keep validation next to the field and explain how to fix an invalid value.
Choose or toggle	`Checkbox` · `Switch` · `Radio Group`	Use a switch for an on/off setting, checkboxes for independent choices, and a radio group for one choice from a visible set.
Reveal related content	`Tabs` · `Accordion` · `Dialog`	Tabs switch between related views; accordions disclose sections. Use a dialog when the task needs focused interaction, with a clear way to close it.
Explain a state	`Alert` · `Skeleton` · `Progress`	Show what is loading, what changed and what the user can do next. A skeleton is temporary structure, not an error or empty state.
Organize information	`Card` · `Table` · `Badge`	Group related content, retain meaningful table headers, and pair status colors with labels. Avoid making every piece of information its own card.

A component or a complete block?

Choose a component when you are building one interaction or refining an existing screen. Choose a block when you need a complete starting composition such as a sidebar, login page or application shell. Blocks reuse the same primitives, so the styling and accessibility work you learn here carries over.

Keep the boundary small. Wrap a repeated arrangement when it solves a real problem in your project. Avoid hiding every prop behind a second API before you know which differences your screens need. Start with explicit props and ordinary children; extract a shared wrapper after the pattern becomes clear.

Compose a small, working interface

Work in an already configured Preact project. Follow the installation guide and CSS setup before trying these examples. Import public components from @kamod-ch/ui, use Preact’s useState for local state, and keep the paths below aligned with your own folder structure.

Each example isolates a different responsibility: action hierarchy, a controlled value, or layout. Copy the source into your app and connect real behavior there. The examples do not introduce a router, backend or additional state library.

Let variants establish the hierarchy

Use one primary action and a quieter alternative. This pair receives callbacks from its parent, keeping routing and service calls in your application.

src/components/EditorActions.tsx

import { Button } from "@kamod-ch/ui";

type Props = { onSave: () => void; onCancel: () => void };

export function EditorActions({ onSave, onCancel }: Props) {
  return (
    <div class="flex flex-wrap gap-2">
      <Button type="button" onClick={onSave}>Save changes</Button>
      <Button type="button" variant="outline" onClick={onCancel}>
        Cancel
      </Button>
    </div>
  );
}

Check the result

Use type="submit" inside a form when the action should submit it. For an asynchronous save, keep pending and error state in the parent and prevent duplicate submissions.

Open button API reference

Connect state without losing behavior

Give each value one owner

Read the component’s API to choose controlled or uncontrolled usage. A controlled component receives its current value and reports changes to its parent; an uncontrolled component owns its local value after initialization. A defaultValue or defaultChecked is an initial value, not a way to update state later. Prop names vary by component: verify them rather than assuming every control uses onChange.

Share state only as widely as the interaction requires. Keep an open menu local unless another part of the screen needs to control it. Put a saved preference in the app’s state or service layer, and distinguish the current input, the pending request, and the last saved value. This makes cancellation and recovery easier to explain.

Preserve labels, focus and semantics

A placeholder is not a label. Connect a visible Label to its control using matching htmlFor and id values. Use unique IDs for repeated instances, link supporting text with aria-describedby, and give icon-only actions a meaningful aria-label. Keep decorative icons out of the accessible name with aria-hidden.

Preserve the documented trigger/content composition for menus and dialogs. Avoid nesting buttons inside links or adding click handlers to non-interactive text. Check Tab, Shift+Tab, arrow keys and Escape wherever the component supports them, then confirm focus returns to a useful place after closing an overlay.

Design the states around the happy path

A successful preview is one state. Add explicit loading, empty and failure states for real requests. Disable repeat submissions while an operation is pending and describe the next step when it fails. Keep useful input intact so a person can retry without starting over. Use an Alert for persistent feedback and reserve announcements for changes that need attention.

Make it your own

Set up once, reuse everywhere. These guides apply to individual components and complete blocks. Start with the global stylesheet and Tailwind CSS source detection, then choose your theme and finish with consistent icons. Following this order makes it easier to tell a setup issue from a change you want to make to the design.

Keep your app’s existing conventions and connect the shared foundation before overriding local classes. Each guide below focuses on one part of that setup and includes a quick visual check. Once the basics look right, use real content to review spacing, contrast and keyboard behavior in both light and dark modes.

Foundation01

Connect your styles

Connect Tailwind CSS, load the global styles and check source detection before your first render. Keep the stylesheet at your app’s entry point so every page shares the same foundation. When you copy a block into src/components, make sure its files are included in source detection so the classes used by the layout are generated.

Appearance02

Customize the theme

Choose a preset, explore light and dark modes, then adjust shared tokens with @kamod-ch/themes. Update --primary and other semantic tokens to carry your brand across the whole interface. Prefer shared tokens for recurring colors instead of restyling every component separately, and check muted text, borders and focus rings against your page background.

Details03

Explore the icon library

Complete navigation and actions with typed @kamod-ch/icons that inherit your interface’s colors. Import the icons you need and keep their size and stroke consistent across related controls. Pair unfamiliar actions with visible labels; when space calls for an icon-only button, give it an aria-label that describes the action.

Work with the source

A useful next step: read the piece you want to change. These two repositories cover the components and visual details behind the library. Check the README and the version in your package.json when comparing an example with your installed API.

Review the screen you will ship

Review the assembled interface with real content, not just each component in isolation. Layout, routes and service responses introduce conditions that a standalone example cannot cover. Use these checks after your first integration and after substantial styling changes.

Content and layout. Try empty values, long names, translated labels and enlarged text. Test a narrow phone and a wide desktop. Confine horizontal scrolling to tables or code; keep primary actions reachable.
Theme and focus. Check the actual theme preset in both light and dark modes. Review foreground/background pairs, disabled controls, validation messages and visible keyboard focus.
State and recovery. Simulate slow and failed requests. Check repeat submissions, cancellation and retry. Decide which state should survive navigation or a reload, and make persistence an explicit application concern.
Production output. Run the scripts your project defines in package.json, including its typecheck, tests and production build. Serve that output and visit a nested route directly to verify assets, styles and initialization.

If a component looks unstyled, revisit global CSS and source detection before adding local overrides. If behavior differs from the docs, compare your installed package version with the relevant API and reduce the issue to a small reproduction. Include that example and the affected browser when reporting it.