Reka UI: headless Vue primitives for accessible design systems

What Reka UI solves, and who it is for

Reka UI is a Vue component library with no styling. The README describes it as a way to "Craft accessible web apps with Vue", and the repository topics list it as headless, accessible and part of the design-system toolchain. That single decision, shipping behaviour without appearance, defines both its audience and its limits.

The audience is Vue and Nuxt teams that already have a visual language, or intend to build one. If your designers hand you tokens and spacing rules rather than a component kit, Reka UI gives you the interaction layer: dialogs that trap focus, selects that respond to arrow keys, tooltips that open on hover and focus. You write the CSS. Nothing arrives with a border radius or a colour.

The project is not new. It was previously called Radix Vue, and the credit section of the README points to Radix UI, React Spectrum, Floating UI and Headless UI as the open-source works it draws on. That lineage matters when you evaluate it: the API shapes and the accessibility model are inherited from a React-native sibling, then adapted to Vue's slot and composition model. If your team has used Radix UI in React, the mental model transfers, but the component names and props will not match line for line.

It is the wrong tool for a marketing site that needs a polished button and a card by Friday. It is also the wrong tool if your organisation standardises on one codebase across React and Vue, because Reka UI is Vue only. The related searches people run, such as "Reka UI react" and "reka ui vs shadcn", suggest this is a common point of confusion rather than an advertised capability.

How the headless primitive model works in practice

The mechanism is composition through slots. A primitive exposes the accessible behaviour and the ARIA wiring, and you supply the elements it renders. The documentation site is the reference for the exact prop and slot names per component; the README itself only points there and gives no API table.

What the repository layout does tell you is how the code is organised. The workspace is defined in pnpm-workspace.yaml with packages/*, and the root package.json builds two filters in sequence: reka-ui and plugins. The core package lives under packages/core, which is also where the release script runs from. Documentation is a separate workspace under docs/, built with VitePress, and the interactive component stories live under .histoire/ and run through Histoire rather than Storybook.

That split has a practical consequence. The library you install and the site you read are separate packages with separate build commands. The docs are generated, not hand-maintained in isolation: there are docs:gen, docs:contributors and docs:sponsors scripts in the root package.json, so API pages are produced from source. When you read a prop table on reka-ui.com, you are reading output from the same code that ships to npm.

Accessibility is the product, not a feature flag. The repository topics include accessibility and accessible, and the primitives are the layer where keyboard handling and focus management live. That also means the responsibility is split: the library can implement focus trapping, but it cannot know whether your custom trigger is reachable by keyboard. The headless model moves the accessible behaviour into the library and keeps the accessible result dependent on your markup.

Installing Reka UI and wiring a first tooltip

The README gives three package-manager commands and nothing else for installation. Pick the one that matches your lockfile; the package name is reka-ui in all three cases.

pnpm add reka-ui

The alternatives are npm install reka-ui and yarn add reka-ui. The README does not document a peer dependency range, a Vue version floor or a Nuxt module name, so check the package metadata under packages/core before you upgrade an existing app.

After installation, the documentation is the place to find the component API. The README links to a getting-started page and an examples page on reka-ui.com, and the repository ships a playground/ directory plus a Histoire storybook for browsing components locally. The tooltip, dialog, select, combobox, popover and checkbox entries that people search for are all documented on the site rather than in the readme.

To browse the primitives against real markup before writing your own, clone the repository and use the documented dev setup. The README lists the commands for both the docs site and the storybook.

pnpm i
pnpm story:dev

The README states that this runs Histoire and that you open http://localhost:6006. For the documentation site instead, the sequence is pnpm i, then pnpm build, then pnpm docs:dev, and the README gives http://localhost:5173 as the address. Note the README numbers the docs steps with a repeated 3, so follow the command names rather than the numbering.

Where Reka UI stops and you have to take over

The most honest limitation is the one in the name: headless means unstyled, and unstyled means every visual state is your problem. Focus rings, disabled colours, hover feedback, transitions, dark mode and reduced-motion handling are not in the package. If your team has no CSS architecture, adding Reka UI does not remove work; it relocates work from component selection to component styling.

There is a second limitation that is easy to miss. A headless primitive can be accessible in isolation and inaccessible in composition. If you render a tooltip trigger as a div with a click handler, the library's positioning and ARIA attributes will be correct and the result will still be unusable by keyboard. The project cannot enforce this, and the README does not claim it does.

The dev setup has a smaller friction point worth knowing before you contribute. The README instructs you to run pnpm build before pnpm docs:dev, so the docs site depends on a local build of the core package rather than resolving the published one. On a fresh clone that is an extra step that can fail quietly if the build errors, leaving you reading a stale site.

Finally, versioning. The current release is v2.10.5, published on 2026-09-21, with v2.10.4 on 2026-08-25 and v2.10.3 on 2026-08-10. The default branch is v2. That cadence is fine, but the README does not document a deprecation policy or a rollback procedure for a broken minor, so pin your version and read the release notes before moving.

Reka UI compared with shadcn-vue and PrimeVue

The searches people run, "reka ui vs shadcn vue", "reka ui vs primevue" and "reka ui vs nuxt ui", point at three genuinely different approaches rather than three flavours of the same thing.

shadcn-vue is not a competing primitive layer; it is a distribution model built on top of one. Its components are copied into your repository and styled with Tailwind, so you own the source and edit it directly. Reka UI is the opposite: you install a dependency and receive updates, but you do not own the internals. The trade-off is control against maintenance. Copying components in means no upgrade path beyond re-copying; depending on a package means upgrades arrive whether or not you have reviewed them.

PrimeVue is a full component suite with themes. You get a data table, a calendar, a file upload and a visual identity in one install. Reka UI deliberately does not compete there. It gives you the interaction layer and expects you to assemble the surface. If your product needs a rich data grid with sorting, filtering and virtual scrolling, PrimeVue is the shorter path, and Reka UI alone will not close that gap.

Nuxt UI sits closer to Reka UI in spirit but bundles more. It targets Nuxt specifically, while Reka UI is framework-level Vue and works in any Vue app. The distinction to hold onto is that Reka UI answers "how should this behave and what ARIA does it need", and the other libraries answer "what should this look like and how fast can I ship it".

Maintenance, upgrades and the MIT licence

Reka UI is not archived, and the last push to the repository was on 2026-09-21, the same day as the v2.10.5 release. Releases have landed roughly every two to three weeks across August and September 2026. That is a steady cadence, and the version numbers stay within the v2 line, so minor upgrades should be routine rather than migrations.

The upgrade cost is mostly the cost of a dependency you do not vendor. Because the primitives are unstyled, a breaking change usually shows up as a changed prop, slot or emitted event rather than a visual regression, and your own CSS will not tell you it broke. That argues for reading the release notes on the GitHub releases page, which the README links to, before bumping. The repository also carries a Renovate configuration, which suggests dependency updates are automated on the maintainer side, but that says nothing about your application.

Tooling expectations are explicit. The root package.json pins [email protected] as the package manager and TypeScript 5.8.3, with ESLint 10 and a commitlint configuration that extends @commitlint/config-conventional. A simple-git-hooks setup runs lint-staged on pre-commit and commitlint on the commit message. If you contribute, your commit messages must follow the conventional format or the hook will reject them.

The licence is MIT, declared both in the repository's LICENSE file and in the root package.json. MIT is permissive: it allows commercial use, modification and redistribution with the copyright notice retained. It does not grant trademark rights, and it comes with no warranty. This is a description of the licence text, not legal advice; have your own counsel review it if your distribution model is unusual.

Editorial conclusion

Adopt Reka UI if you are building a Vue or Nuxt design system and can own the styling, the markup and the accessibility testing yourself. Do not adopt it if you want finished visual components or a component set that also targets React. Before committing, check the v2.10.5 release notes against the primitives you plan to use, confirm your Vue version satisfies the peer range declared in packages/core, and decide how you will test keyboard navigation and focus behaviour, because the library supplies the behaviour and leaves the verification to you.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. unovue/reka-ui on GitHub