Components

AsheeUI ships 61 components. Every one of them resolves its appearance through the configuration cascade, composes with consumer className for layout, and renders on the server without a browser.

The set is layered, so you can build at the level your page needs:

primitive        Button, Input, Typography, Badge
        ↓
component        Modal, Tabs, Dropdown, Calendar
        ↓
pattern          Card, EmptyState, DataTable, PricingCard
        ↓
layout           Container, Section, Stack, Grid, Centered, Split, Page
        ↓
composition      MarketingLayout, DocsLayout, SidebarLayout, AuthLayout
        ↓
page             Navbar, Hero, FeatureGrid, CTA, Footer
        ↓
Puck block       any of the above, through @asheeui/puck

Every component, at a glance

The grid below is generated from the package's public exports: a component appears here only if it is exported, and every card links to the page that documents it.

gallery

Shared prop axes

Most components accept the same four axes, which is what makes a global configuration able to restyle the whole framework.

Each component documents its own props with JSDoc, so the TypeScript types are the reference: hovering a prop in the editor shows its purpose, its default and an example.

The components

Inputs and controls

Data display

Navigation

Overlays and feedback

Layout

The layout components own structure and nothing else. Each one adds a real layout behaviour (a maximum width, a rhythm, an axis, a breakpoint, a shell), so they compose instead of wrapping.

Compositions

A composition arranges whole pages from the layers below it. It owns the page's landmarks and nothing about its content.

Layouts documents the layer in full, with a worked example of each composition.

The layout components never couple to a router, to application state or to a particular product. PageContent is the one main landmark of a page, and the shells stack their regions on a narrow screen rather than hiding them.

Patterns

A pattern is a reusable combination of components that is still free of any application's content.

A configured action describes a destination, so an action that runs a handler is passed to a pattern as a child (EmptyState also takes actions for that, which renders it inside the pattern's own action group). The two forms are not interchangeable, and the rule keeps a pattern's props serializable for a visual editor.

Pages and marketing sections

Every one of these takes its actions as configuration:

<Hero
  eyebrow="Everything in one place"
  title="Run your campaigns from a single workspace"
  primaryAction={{ label: "Start free", href: "/signup" }}
  secondaryAction={{ label: "Book a demo", href: "/demo", variant: "ghost" }}
  media={<Image src="/dashboard.png" alt="The campaign dashboard" />}
/>

An action is { label, href, variant, color, size, radius, icon, component, componentProps }, which is the same set of choices a Button takes. Icons, custom link components and handlers stay in React rather than in configuration, which is what keeps the same props usable as a Puck field set.

The substitution API

Link, Image and Form each render a native element that a framework usually replaces. All three take the same two props, so one pattern covers them:

import NextLink from "next/link";
import NextImage from "next/image";

<Link href="/invoices" component={NextLink} componentProps={{ prefetch: true }}>
  Invoices
</Link>

<Image src="/logo.png" alt="Logo" component={NextImage} componentProps={{ priority: true }} />

Components that render one of the three forward the same pair for the element they compose: a Breadcrumb step accepts component and componentProps for its link, and Avatar and Card accept them for their picture.

Field components

The field components (Input, Textarea, Dropdown, MultiSelect, Autocomplete, Radio, Switch) share one field contract:

Native attributes (disabled, readOnly, placeholder, name, value, defaultValue, onChange, onBlur) pass straight through, so a field works with a plain form and with a form library.

Contexts that read the theme

useTheme reads and changes the theme, and useToast raises a notification from anywhere inside the provider:

const { success } = useToast();

success("The invoice was updated.");

useToast also returns toast for a fully specified notification, the error, info and warning helpers alongside success, and removeToast and clearToasts for dismissing one or all of them.

Recipes

Some screens are a composition of what the framework already ships, and a component of their own would duplicate one of the parts.

A command palette

A command palette is a modal that searches a list and closes when a command runs. The framework's parts are the modal, the search field and the list:

const [query, setQuery] = useState("");
const [open, setOpen] = useState(false);

<Modal isOpen={open} onClose={() => setOpen(false)} aria-label="Commands" size="sm">
  <VStack gap="sm">
    <SearchInput
      placeholder="Search commands"
      shortcut="Cmd K"
      onValueChange={setQuery}
    />
    <Sidebar
      items={commands.filter((command) => matches(command, query))}
      onSelect={(item) => {
        run(item.id);
        setOpen(false);
      }}
    />
  </VStack>
</Modal>;

Modal supplies the focus trap, the dismissal and the escape key, SearchInput supplies the named search region and the query, and the list supplies the keyboard navigation. A dedicated component would have to re-implement all three.

A table page

DataTable is the recipe, and the parts stay reachable: pass a toolbar for filters, searchAccessor for client-side search, or onSearchChange to search on the server and replace the rows.

Next

• Accessibility for keyboard behaviour and the announced state.
• Puck for the same components in a visual builder.
• CLI for listing the components a version exports.

Reading a page

Every component page has the same shape, so the part you need is always in the same place:

Looking for a starting point rather than a reference? Page compositions shows these assembled into a page.