# Usage (/ui/docs/react/usage)



Once Appica UI is [installed](/ui/docs/react/installation), every component follows
the same small set of conventions. Learn them once and the whole library feels
consistent.

## Importing components [#importing-components]

Import each component from its own subpath. This keeps bundles minimal — your app
only pulls in what it uses, even without a bundler that tree-shakes barrel files.

```tsx
import { Button } from '@appica/ui-react/button'
import { Input } from '@appica/ui-react/input'
import { Dialog, DialogTrigger, DialogContent } from '@appica/ui-react/dialog'
```

Every export is also available from the package root, which is convenient for
prototyping:

```tsx
import { Button, Input } from '@appica/ui-react'
```

<Callout type="tip">
  Prefer subpath imports (`@appica/ui-react/button`) in application code. Reserve the root import for quick experiments.
</Callout>

## Variants and sizes [#variants-and-sizes]

Visual style is controlled through a `variant` prop, and dimensions through a
`size` prop. The available values differ per component, but the prop names stay
consistent across the library.

```tsx
<Button variant="primary">Primary</Button>
<Button variant="outline">Outline</Button>
<Button variant="ghost" size="sm">Small ghost</Button>
```

Each component documents its own `variant` and `size` options on its page. Need
the union type in your own code? Derive it from the component's props rather than
reaching for an internal type:

```tsx
import type { ComponentProps } from 'react'
import { Button } from '@appica/ui-react/button'

type ButtonVariant = ComponentProps<typeof Button>['variant']
```

## Styling and overrides [#styling-and-overrides]

Components are themed entirely through [design tokens](/ui/docs/react/theming), so
they adapt to your colors and dark mode automatically. For one-off tweaks, pass
`className` — it's merged intelligently (conflicting Tailwind utilities are
de-duplicated), so your class wins:

```tsx
<Button className="w-full rounded-full">Full width</Button>
```

## Composition [#composition]

Most components accept a `render` prop to change the element they output — for
example, rendering a `NavigationLink` as your router's `Link`. This is the key to
composing Appica UI with your router and your own components:

```tsx
import Link from 'next/link'
import { NavigationLink } from '@appica/ui-react/navigation'

<NavigationLink render={<Link href="/pricing" />}>Pricing</NavigationLink>
```

See [Composition](/ui/docs/react/composition) for the full pattern, including how to
merge classes and when overrides belong on the wrapper.

## Server Components [#server-components]

Appica UI works out of the box with React Server Components and the Next.js App
Router. Interactive components carry their own `'use client'` boundary
internally, so you can import them directly into a Server Component without
marking the whole page client:

```tsx title="app/page.tsx (Server Component)"
import { Button } from '@appica/ui-react/button'

export default function Page() {
  return <Button>Works in an RSC</Button>
}
```

<Callout type="note" title="Crossing the server/client boundary">
  You can render Appica UI components from Server Components, but you can't pass non-serializable props (functions like
  `onClick`, or `render={<ClientComponent />}`) across the boundary. Move that interactivity into a `'use client'`
  component of your own. Providers like `ThemeProvider` are client components — keep them inside a client boundary (your
  root layout's `body` is fine).
</Callout>

On a client-only stack (Vite, CRA, or any single-page app) there's no
server/client split to think about: import and use components normally. The
`'use client'` directives you'll see throughout these docs are a no-op there —
bundlers without React Server Components simply ignore them.

## Next steps [#next-steps]

* [Composition](/ui/docs/react/composition) — the `render` prop in depth.
* [Theming](/ui/docs/react/theming) and [Dark Mode](/ui/docs/react/dark-mode).
* [Forms & Validation](/ui/docs/react/forms) — build accessible forms.
