Compatibility

Almost anywhere you already write Vue. Vuetify0 is headless — it ships reactive-logic composables and unstyled primitives, no CSS, and requires no global plugin — so it sits in the behavior layer of your app and rarely competes with what you already use.

No global install and no CSS

v0 registers nothing globally and paints no pixels. You import what you need (import { createSelection } from '@vuetify/v0') and it tree-shakes. Because it emits no styles and installs no plugin, there is nothing for it to collide with:

• No CSS to clash with your component library’s theme or reset.

• No app.use() to duplicate or fight another plugin’s install.

• No opinion about your styling, router, state manager, or build tool.

So the default answer to “can I use Vuetify0 with X?” is yes. The rest of this page is the small number of exceptions and the guidance for mixing well.

Compatibility at a glance

Styled component libraries

Libraries like Vuetify, PrimeVue, Quasar, Element Plus, and Nuxt UI render finished, themed UI. v0 renders behavior. They occupy different layers, so they stack: let the styled library paint the pixels, and reach for Vuetify0 when you need interaction logic or an orchestration primitive the library doesn’t expose — a nested-tree selection model, a shared registry across several of your own components, a stepper, a virtualized list.

The only recurring caveat is redundancy, not conflict. Every styled library ships its own services for theme, locale, RTL, breakpoints, and z-index — the same concerns v0’s optional plugin composables (useTheme, useRtl, useLocale, useBreakpoints, useStack) also cover. Don’t run both for one concern. Pick a single owner, and in a styled-library app that owner is normally the styled library.

• Vuetify — a special case: Vuetify0 is Vuetify’s own substrate, adopted incrementally through minor releases. In a Vuetify app today, use Vuetify0 for headless logic Vuetify doesn’t yet surface directly, and let Vuetify own theming and display. Vuetify is not fully reimplemented on Vuetify0 — treat v0 as the shared foundation underneath, not a drop-in replacement for Vuetify’s components.

• Quasar — Quasar’s stylesheet includes a global reset that restyles base elements app-wide. It won’t touch v0’s logic, but v0’s unstyled elements will inherit Quasar’s base styling. Scope or override where you don’t want it.

• PrimeVue / Element Plus — component-scoped CSS, no aggressive reset; both support SSR and plugin-free auto-import. Use v0 for what they lack, not to re-solve their built-in toast/dialog/config providers.

Headless libraries

Reka UI (formerly Radix Vue — the same project, renamed), and Headless UI live at the same layer as v0: unstyled, accessibility-focused behavior. You can technically install them alongside v0 — everything is tree-shakeable and nothing collides — but stacking two headless libraries on the same widget is redundant, not additive. You’d maintain two accessibility implementations for one concern.

Guidance if you’re already invested in one: keep it for the primitives you’re happy with, and adopt v0 above that layer for the orchestration it adds — selection systems, registries, form and validation coordination, data-table/filter/pagination/virtual pipelines. Don’t rebuild working widgets on Vuetify0 for its own sake. Note that Nuxt UI is built on Reka UI, so “using Vuetify0 with Nuxt UI” is already a Reka-based stack — the same answer applies.

VueUse

Use both — they’re complementary. VueUse is a general-purpose reactivity and browser utility belt (useFetch, useClipboard, useMouse, and hundreds more). Vuetify0 is a headless UI-component logic layer whose create* orchestration primitives (selection, registry, form, combobox, data table) solve a problem VueUse never set out to.

The overlap is shallow and confined to the lowest tier: Vuetify0 ships its own useEventListener, useResizeObserver, useIntersectionObserver, useMutationObserver, useMediaQuery, useBreakpoints, useClickOutside, useStorage, useRaf, useTimer, and useHotkey — because its components need them internally and it avoids a hard dependency on VueUse. Those are the only names that collide, and the collision is import-scoped only: alias one side if both land in the same file.

import { useStorage } from '@vueuse/core'
import { useStorage as useV0Storage } from '@vuetify/v0'

The two implementations run side by side without interfering. Same name does not mean same signature, though — Vuetify0’s versions are tuned for its components and SSR guarantees, so check each library’s own types rather than passing one’s options to the other.

Frameworks and SSR

Vuetify0 works in any Vue setup with no special integration.

• Vite — the default target. Import and go.

• Nuxt / SSR — Vuetify0 is SSR-safe: browser APIs are gated behind an IN_BROWSER guard, persisted state falls back to in-memory on the server, and useHydration lets you defer client-only rendering past the first paint. There is no v0-specific Nuxt module, and none is needed. See the Nuxt guide.

• Astro — use Vuetify0 inside Vue components rendered as islands; its reactive logic activates wherever the island hydrates (client:*).

• Vapor — Vuetify0 runs under Vue’s Vapor mode. See the Vapor guide.

Three rules for mixing

1. One owner per concern. Theme, locale, RTL, breakpoints, z-index — Vuetify0 and your styled library both offer these. Choose one source of truth; in a styled-library app it’s usually the styled library’s.

2. Same layer, pick one; different layer, stack freely. v0 + a styled library = different layers, combine them. v0 + another headless library = same layer, don’t double up on a single widget.

3. SSR: guards prevent crashes, useHydration prevents mismatches. The library keeps the server from throwing on browser APIs; isHydrated is what you use to keep your own conditional markup consistent across the server-to-client handoff.