Components

shadcn's component library, as source your app owns. whitehall add button copies Button.wh into src/lib/components/ui/, the way npx shadcn add button does.

whitehall add button

import $lib.components.ui.Button

<Button variant="outline" onClick={save}>Save</Button>

From then on the file is yours: edit its classes, add a variant, delete what you do not use. A second add refuses rather than overwrite it. Using <Button> without the import is a build error that names both steps.

The shape of a component

A component takes its variants as props. <Button> has shadcn's six variants and eight sizes:

<Button variant="destructive" size="sm" onClick={remove}>Delete</Button>

<Button variant="outline">
  <Icon name="lucide:plus" />
  Add item
</Button>

See it happen

Switch between these to see the props on the same tag, compiled live in your browser.

import $lib.components.ui.Button

<Button onClick={save}>Save</Button>

Slots

A multi-part component is written the way shadcn writes it, as nested tags. Each part is a tag of its own:

<Card>
  <CardHeader>
    <CardTitle>Total revenue</CardTitle>
    <CardDescription>Last 30 days</CardDescription>
  </CardHeader>
  <CardContent>
    <Text class="text-3xl font-bold">$45,231.89</Text>
  </CardContent>
  <CardFooter>
    <Button variant="outline">View report</Button>
  </CardFooter>
</Card>

That is 217 tags across 55 roots. A slot tag only compiles inside its own parent — a <CardFooter> written anywhere else is an error rather than a call that does not exist.

Anchored components

Popovers, menus, tooltips and selects position themselves against whatever triggered them:

<DropdownMenu>
  <DropdownMenuTrigger>
    <Button variant="outline">Open</Button>
  </DropdownMenuTrigger>
  <DropdownMenuContent>
    <DropdownMenuLabel>My account</DropdownMenuLabel>
    <DropdownMenuSeparator />
    <DropdownMenuItem>Profile</DropdownMenuItem>
    <DropdownMenuItem>Settings</DropdownMenuItem>
  </DropdownMenuContent>
</DropdownMenu>

Writing your own

A component you write yourself is the same kind of file as Button.wh: it can take the caller's markup, and it can take the caller's classes.

Children

A component that wraps its caller's markup puts a <slot /> where that markup goes, the same as a layout does:

// src/components/Card.wh
<Box class="rounded-2xl border p-16">
  <slot />
</Box>

// anywhere
<Card>
  <Text>Hello</Text>
</Card>

The generated function takes Compose's trailing lambda, so the call site reads as a block rather than an argument — and the parameter is defaulted, so <Card /> with no children still compiles:

fun Card(modifier: Modifier = Modifier, content: @Composable () -> Unit = {})

class at the call site

A class on a component you wrote lands on that component's root element, the same as it would on a <Box>:

<UserCard class="mt-4 w-full" />

UserCard(modifier = Modifier.padding(top = 16.dp).fillMaxWidth())

The generated composable takes modifier: Modifier = Modifier — Compose's own convention — and applies it to its root before that root's own modifiers. A class from outside therefore layers underneath what the component draws, which is what makes <UserCard class="backdrop-blur-xl" /> frost the content behind the card rather than paint over it.

A component that declares @prop val class: String = "" takes the caller's classes itself instead, and puts them where it wants them — last in its own list, the way Button.wh does, so they win over its defaults as shadcn's cn() has it: <Row class={[base, variantClasses, class]}>.

A component with more than one root element takes one too: multiple roots are auto-wrapped in a Column, and the wrapper is what the class lands on. Screens and layouts do not take a class — nothing writes <HomeScreen class="…" />, the router reaches them.

The library

shadcn's own alphabetical order. Root tag is what you write; components with slots list the count of tags in the family.

Single tag

With slots

Compositions, not tags

Three of the 58 are shadcn recipes rather than components. They have no tag of their own:

The five that are not here

Leaving one out is a decision, and the reasoning is written down rather than implied. Two are deferred; three do not apply.

What does not survive the translation

The generated Kotlin is a transcription, not an interpretation. Where Compose cannot express what shadcn does, the gap is listed rather than approximated:

• Focus rings. shadcn's focus-visible: ring is a keyboard affordance. A touch screen has no focus-visible state, so it is deliberately not ported.
• Hover. hover: variants have no touch equivalent; the pressed state carries the feedback instead.
• Text metrics. Android's text is a few pixels tighter than the browser's at the same size. This is a HarfBuzz-versus-browser difference, not a bug to be tuned out.

See Also

• Theming — the preset that turns these on
• Tailwind Classes — the utility classes components are styled with
• Layout — <Column>, <Row>, <Box>