When you think about a UI component library, you probably picture something
visual: buttons, dropdowns, date pickers. What you might not immediately think
about is everything that has to work beneath the visual surface for those
components to be truly usable. The select component has to fetch the list of
options using an API call, and fetch the next page as the user scrolls. The date
picker has to manage focus correctly so navigating with a keyboard is possible.
You expect the popover to work on mobile, and the tooltip must be clickable on
touch devices. All of this is invisible to the user, but it's what separates a
component that looks right from one that actually works.

## Why rolling your own is harder than it looks

A `<button>` and a `<select>` in plain HTML get you somewhere. But the moment
you build anything slightly more complex, a combobox with filtering, a
multi-select with tags, a date range picker, you're on your own.

Take a custom dropdown. It's usually a `<div>` with a click handler that toggles
a list. Looks fine on screen. But there's no keyboard navigation, no focus
management, no touch handling on mobile, no correct behavior when the popover
needs to reposition near the edge of the viewport. None of that comes for free.
Implementing it correctly for a single component takes days. Doing it for a full
suite of components takes months, and you'll still hit edge cases you didn't
anticipate.

At some point, you either accept that your components will be half-broken, or
you reach for a library that has already paid that cost.

## We considered MUI, and decided against it

Material UI (MUI) is one of the most popular React component libraries out
there. It gives you a full set of production-ready components -- buttons, forms,
tables, dialogs, date pickers -- all styled according to Google's Material
Design guidelines. The components look polished out of the box. The problem is,
they look like MUI. That aesthetic is immediately recognizable, and once you've
seen it you can't unsee it.

When we started building Plakar UI, it was the obvious candidate. It's
comprehensive, battle-tested, and has a massive community. We spent some time
seriously considering it.

But we were working with [Pelostudio](https://pelo.studio/) on our visual
identity. They helped us define our fonts, our colors, our mascot, the whole
design system. Shipping a product that looks like every other MUI app on the
internet was not an option. We wanted something that looks like Plakar, and that
meant picking a library that stays out of the way visually.

![Plakar UI -- the design system defined with Pelostudio](./plakar-ui-design.png)

## We started with Headless UI

Unstyled component libraries separate interaction logic from visual design. You
style everything yourself; the library handles the behavior.

The first version of Plakar UI was built on
[Headless UI](https://headlessui.com/). If you use Tailwind, it's almost the
natural choice: Tailwind's own documentation and code examples use Headless UI
throughout, so you end up reaching for it without much deliberation. It worked
well for what it offered, but the catalog was limited, around a dozen
components. There was no date picker, no combobox with filtering, a fairly basic
select. For anything beyond those primitives, you were back to building from
scratch. We also hit a few frustrating bugs that we never fully tracked down.
Nothing catastrophic, but enough friction that we started looking at
alternatives.

The real push was component breadth. We needed more, and Headless UI wasn't
going to get us there.

## Enter React Aria Components

[React Aria Components](https://react-spectrum.adobe.com/react-aria/components.html)
is Adobe's take on unstyled interactive components. It's part of the React
Spectrum family, which powers Adobe's own products, and the depth of the catalog
reflects that.

Where Headless UI offers around a dozen components, React Aria ships over forty.
Every component ships with correct keyboard navigation, focus management, touch
support, and proper behavior across browsers. A few of the less obvious ones
that we actually use: DateRangePicker, RangeCalendar, TagGroup, Slider. The work
has been done; you just compose and style.

The learning curve is real. React Aria doesn't give you a single `<Select />`
with twenty props. Instead it gives you building blocks, `Select`,
`SelectValue`, `ListBox`, `ListBoxItem`, `Popover`, `Button`, that you assemble
yourself. This feels verbose at first, but it's exactly what makes the library
so flexible.

## A concrete example: multi-select with search

Here's how we build a multi-select component in Plakar UI, one that lets users
pick multiple options from a searchable dropdown list. This is the kind of
component that would take days to implement correctly from scratch.

With React Aria, you assemble it from primitives:

```tsx
<Select selectionMode="multiple">
  <SelectValue />
  <Popover>
    <Autocomplete>
      <SearchField />
      <ListBox>{(option) => <ListBoxItem>{option.name}</ListBoxItem>}</ListBox>
    </Autocomplete>
  </Popover>
</Select>
```

Each component has a single job. `Select` owns the selection state.
`SelectValue` renders what's currently selected. `Popover` handles the dropdown
positioning and dismissal. `Autocomplete` wires the search field to the list so
filtering works. `SearchField` is the input. `ListBox` and `ListBoxItem` are the
actual options.

You didn't write any of that interaction logic. You just described the
structure, and React Aria filled in the behavior.

![MultiSelect with the dropdown open, search field focused, and selected items shown as tags](./multi-select.png)

React Aria applies `data-*` attributes to elements based on their state:
`data-focused`, `data-selected`, `data-disabled`, `data-hovered`,
`data-pressed`, and so on. Tailwind's arbitrary variant syntax lets you target
these directly:

```tsx
<ListBoxItem
  className={clsx(
    "rounded px-2 py-1.5 text-sm",
    "data-focused:bg-gray-100",
    "data-selected:bg-blue-50 data-selected:font-medium",
    "data-focused:data-selected:bg-blue-100",
    "data-disabled:cursor-not-allowed data-disabled:opacity-50",
  )}
>
  {option.name}
</ListBoxItem>
```

Your hover and focus styles are driven by React Aria's state machine rather than
CSS pseudo-classes. This matters because `:hover` doesn't apply during keyboard
navigation, but React Aria's `data-focused` does.

## Async data out of the box

Multi-select with local options is useful, but a lot of what we build in Plakar
UI needs to fetch data from an API. React Aria ships with `useAsyncList` from
`react-stately`, and this is where the library earns its place most clearly.

Here's a resource picker that fetches from an API and filters results as the
user types:

```tsx
import {
  ComboBox,
  Input,
  ListBox,
  ListBoxItem,
  Popover,
} from "react-aria-components";
import { useAsyncList } from "react-stately";

type Resource = { id: string; name: string };

export function ResourcePicker() {
  const list = useAsyncList<Resource>({
    async load({ signal, filterText }) {
      const res = await fetch(`/api/resources?q=${filterText ?? ""}`, {
        signal,
      });
      const items = await res.json();
      return { items };
    },
  });

  return (
    <ComboBox
      items={list.items}
      inputValue={list.filterText}
      onInputChange={list.setFilterText}
      isLoading={list.isLoading}
    >
      <Input placeholder="Search resources..." />
      <Popover>
        <ListBox>
          {(item) => <ListBoxItem id={item.id}>{item.name}</ListBoxItem>}
        </ListBox>
      </Popover>
    </ComboBox>
  );
}
```

About twenty lines of code. In-flight requests are cancelled automatically via
`AbortSignal`, so there's no debouncing to wire up and no stale responses
landing out of order. The loading state is tracked and exposed through
`isLoading` so you can show a spinner without any extra flags. If your API
returns a `cursor` from `load`, pagination just works. And there's no
`useEffect` anywhere in this; no manual loading flag, no request cancellation on
unmount. All of that is inside `useAsyncList`.

![ResourcePicker: loading state on the left, filtered results on the right](./resource-picker.png)

## The composability payoff

The verbose composable API pays off when you need to deviate from a standard
pattern. Want a "Select all" button at the top of the list? Add a `Button` above
the `ListBox`. Want to group options under section headers? Use `ListBoxSection`
and `Header` inside `ListBox`. Want a loading spinner instead of options while
fetching? Replace the `ListBox` children with a spinner. React Aria doesn't lock
you into a specific structure.

Compare this to passing `showSelectAll={true}` as a prop and hoping the library
supports exactly the variant you need. With React Aria, you compose it.

This is the same philosophy as TanStack Form's field components or TanStack
Table's headless approach: the library handles the hard invisible stuff, and you
retain full control over the rendering.

## Accessibility comes along for the ride

We didn't choose React Aria primarily for accessibility. We chose it for the
breadth of components and the quality of their interaction logic. But
accessibility comes along for the ride. Every component ships with correct ARIA
roles, keyboard navigation, screen reader announcements, and mobile touch
support. We get that from Adobe's years of refinement across their own products,
without having to think about it ourselves.

Next up: [TanStack Table](../plakar-ui-tanstack-table), and the discovery that a
`<table>` element is not actually the whole story.