Components

shadcn's component library, ported to Compose. 58 of shadcn's 63 components, written as <Tag>s in a .wh file and compiled to Kotlin.

These are generated from shadcn's own style-vega.css rather than wrapped around Material, so an app painted in shadcn's colors has shadcn's shapes too. You get them by default — <Button> is Whitehall's, not androidx.compose.material3.Button.

The shape of a component

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

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

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

See it happen

This embed compiles a single file with no whitehall.toml, so it has no palette to read and variant is off the table — the props below are the ones that work with or without the preset. Switch between these to see props layer onto the same tag, compiled live in your browser.

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

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" text="View report" />
  </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" text="Open" />
  </DropdownMenuTrigger>
  <DropdownMenuContent>
    <DropdownMenuLabel>My account</DropdownMenuLabel>
    <DropdownMenuSeparator />
    <DropdownMenuItem>Profile</DropdownMenuItem>
    <DropdownMenuItem>Settings</DropdownMenuItem>
  </DropdownMenuContent>
</DropdownMenu>

Writing your own

Everything above ships with the preset. A component you write yourself gets the same two affordances — 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 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>