Headless-компоненты

Headless значит: библиотека владеет поведением, ты владеешь DOM. Застилизованный компонент связывает три вещи: поведение (открыть/закрыть, выбор, клавиатура), доступность (роли, aria-*, фокус) и представление (разметка + CSS). Headless-компонент оставляет первые две, а третью отдаёт тебе. Он раскрывает свою работу как хуки, render-props или prop-геттеры — но никогда как готовую разметку.

// Застилизованная библиотека: ты получаешь её <div>, её классы, её структуру. Ты переопределяешь.
<Combobox className="lib-combobox" /* now fight its internals */ />

// Headless-библиотека: она даёт поведение + props доступности; элементы пишешь ТЫ.
const { getInputProps, getMenuProps, getItemProps, isOpen } = useCombobox({ items });
return (
  <div className="my-combobox">
    <input {...getInputProps()} className="my-input" />
    <ul {...getMenuProps()} className={isOpen ? "my-menu open" : "my-menu"}>
      {isOpen && items.map((item, i) => (
        <li key={item.id} {...getItemProps({ item, index: i })} className="my-row">
          {item.label}
        </li>
      ))}
    </ul>
  </div>
);

Библиотека решает, что должны объявлять поле ввода и каждая строка и как стрелки двигают выбор; ты решаешь, как они выглядят и где располагаются.

Ты наследуешь работу по доступности и клавиатуре, которую по-настоящему трудно сделать правильно. В этом и есть настоящая выгода. Корректному listbox нужны role, aria-activedescendant, aria-expanded, aria-controls, перемещающийся фокус (roving), обработка Home/End/PageUp/PageDown, type-ahead и объявления — многонедельный проект, если делать хорошо, и вечный источник багов, когда написан руками. Headless-примитив запекает это в свои prop-геттеры, так что, разложив их по своим элементам, ты получаешь виджет, соответствующий WAI-ARIA, в собственной обёртке.

// Radix headless: нестилизованные, доступные примитивы, которые ты компонуешь и стилизуешь сам.
import * as Dialog from "@radix-ui/react-dialog";

export function ConfirmDialog() {
  return (
    <Dialog.Root>
      <Dialog.Trigger className="btn">Delete</Dialog.Trigger>
      <Dialog.Portal>
        {/* focus trap, Esc-to-close, scroll lock, aria-modal, restore-focus: all free */}
        <Dialog.Overlay className="overlay" />
        <Dialog.Content className="card">
          <Dialog.Title className="title">Delete project?</Dialog.Title>
          <Dialog.Close className="btn-danger">Confirm</Dialog.Close>
        </Dialog.Content>
      </Dialog.Portal>
    </Dialog.Root>
  );
}

Каждый className — твой. Каждая ловушка фокуса, обработчик Esc и aria-modal — библиотеки. Ты не писал ту часть, которую большинство команд делают неправильно.

Кастомный вид не стоит ничего, потому что нет стилей, которые нужно переопределять. С застилизованным набором кастомизация — это вычитание: ты убираешь и переопределяешь то, что пришло в комплекте. С headless кастомизация — состояние по умолчанию: ничего не приходит застилизованным, так что тебе никогда не приходится реверс-инжинирить специфичность CSS библиотеки или её shadow-DOM. Один и тот же headless useReactTable питает и плотную админ-таблицу, и воздушную маркетинговую: поведение общее, разметка расходится полностью.

import { useReactTable, getCoreRowModel, flexRender } from "@tanstack/react-table";

const table = useReactTable({ data, columns, getCoreRowModel: getCoreRowModel() });

// TanStack Table headless: даёт row model + состояние, без <table> вовсе.
return (
  <table className="my-grid">
    <tbody>
      {table.getRowModel().rows.map((row) => (
        <tr key={row.id} className="my-row">
          {row.getVisibleCells().map((cell) => (
            <td key={cell.id} className="my-cell">
              {flexRender(cell.column.columnDef.cell, cell.getContext())}
            </td>
          ))}
        </tr>
      ))}
    </tbody>
  </table>
);

Сортировка, фильтрация, пагинация, группировка — всё поведение, нуль разметки. Ты рендеришь всё, что требует дизайн.

Режим отказа: headless-абстракция для одного внутреннего виджета с ровно одним видом — это спекулятивная общность. Headless оправдывает себя, когда поведение общее, а внешний вид варьируется — по приложению, по дизайн-системе или по множеству потребителей библиотеки. Если у тебя один dropdown, используемый в одном месте с одним дизайном, построить свой headless-слой useDropdown (prop-геттеры, обобщённое состояние, render-props) не покупает ничего: нет второго вида, который нужно варьировать, нет третьего потребителя, которого нужно обслужить. Ты заплатил полную цену абстракции — косвенность, обобщённый API, больше файлов — за гибкость, которой никогда не воспользуешься.

// Переинжиниринг: самодельный headless-слой для ОДНОГО компонента с ОДНИМ видом.
function useDropdown<T>() { /* prop-getters, generic state, a render-prop API… */ }
function AppMenu() {
  const { getToggleProps, getItemProps, isOpen } = useDropdown<MenuItem>();
  // …used in exactly one place, styled exactly one way, forever
}

// Senior-выбор: обычный компонент. Тянись к headless, только когда вариативность реальна.
function AppMenu() {
  const [open, setOpen] = useState(false);
  return /* the one markup this app needs */;
}

Потреблять опубликованную headless-библиотеку (Radix, Headless UI) дёшево и почти всегда правильно — кто-то уже заплатил за абстракцию, и доступность обкатана в бою. Писать свой headless-слой стоит того лишь тогда, когда у тебя действительно есть несколько видов поверх одного поведения.