Glossary
Short definitions of the vocabulary that recurs throughout v0’s docs and source — ticket, registry, trinity, context, and the rest. Each entry says what the term means, why it exists, and where to read more.
The terms build on each other. If you want the full picture of how they connect, read Core — this page is the quick-lookup reference.
Core architecture
Headless
A component or composable that ships behavior, state, and accessibility but no styling — you write every line of CSS yourself.
Why it exists: v0 sits at the bottom of the stack (v0 → Paper → design systems → Vuetify). A single utility class in source would bind every downstream design system to it. The acid test is “strip every stylesheet and the component still functions and announces its state to a screen reader.”
See Styling and Components.
Compound component
A component split into a stateful Root plus named sub-components — Tabs.Root, Tabs.List, Tabs.Item — that coordinate through a shared context rather than through props.
Why it exists: the Root owns the state once; children read it from the context, so siblings never prop-drill state between each other. Each piece stays independently styleable while the behavior stays centralized.
See Components.
Trinity
The signature return shape of v0’s context and plugin factories: a readonly three-element tuple. Context factories return [useX, provideX, defaultX]; plugin factories return [createXContext, createXPlugin, useX].
Why it exists: three elements cover every consumption mode — inject in a child (useX), provide from a parent (provideX), and use standalone or in a test without mounting Vue (defaultX). One predictable shape across the whole library keeps data flow debuggable.
See Core and createTrinity.
Context
A type-safe wrapper around Vue’s provide/inject, created with createContext(key). It returns a [useX, provideX] pair and throws when a consumer injects a context no ancestor provided.
Why it exists: raw inject() silently returns undefined when the provider is missing, turning a setup mistake into a downstream null-reference bug. createContext fails loudly at the injection site and gives full type inference. v0 never calls raw provide/inject outside its two foundation factories.
See createContext and Core.
Namespace
The string key that scopes a context, such as v0:tabs. Production keys are prefixed v0: and must contain a colon.
Why it exists: the colon namespaces the key so independent contexts never collide, and a missing colon triggers a [v0:context] warning. Dynamic-key mode appends a suffix (key:suffix) so one factory can service many disjoint subtrees — nested panels, or tabs within tabs.
See Core.
Plugins and adapters
Plugin
An app-level singleton installed with app.use(...). Built with createPlugin or createPluginContext, a plugin wires an install hook, optional adapters, and optional persist/restore lifecycle hooks.
Why it exists: some state is genuinely global — theme, locale, breakpoints, feature flags. A plugin provides it once at the app root so any component can inject it, instead of threading it through every tree. Plugins are order-independent and degrade gracefully when a dependency is missing.
See createPlugin and Plugins.
Adapter
A swappable backend behind a composable. The composable defines an interface; an adapter implements it against a concrete library — console, pino, or consola for the logger; localStorage or sessionStorage for storage; a date library for dates.
Why it exists: v0 is not a thin wrapper around any one library. Adapters let a consumer keep v0’s API while choosing — or writing — the implementation underneath, and they are the boundary where untrusted input is sanitized before it reaches the DOM.
Registries and tickets
Registry
The indexed store that holds registered items as tickets, created with createRegistry. It is the foundation every selection, form, and token composable extends.
Why it exists: parent-child coordination — which tab exists, in what order, with what value — needs one reactive source of truth keyed by id with stable ordering. Building it once means selection, validation, and data composables all share the same register / get / move surface.
See createRegistry and Core.
Ticket
The plain object you get back when you register an item with a registry. Every ticket carries { id, index, value, valueIsIndex, unregister }, and richer registries add reactive properties and bound methods — isSelected (a ref), select(), toggle().
Why it exists: the ticket is the handle a sub-component holds onto its own slot in the parent’s registry. Reactive fields update automatically as state changes; the bound methods let a child act on itself without knowing the registry’s internals. Ticket types extend their parent and never override the base shape.
See Building Frameworks and Core.
Register, onboard, and unregister
The registry lifecycle verbs. register(ticket) adds one item and returns its ticket; onboard(tickets) bulk-registers many; unregister(id) removes one and offboard(ids) removes many, returning the removed data.
Why it exists: collection composables own their items through this surface instead of accepting an items array option — the registry stays the single source of truth. Sub-components register during setup so sibling order is correct before paint, and unregister in onBeforeUnmount while the context is still reachable.
See createRegistry.
Enroll
Distinct from register, enrollment is auto-selection on registration. createModel enrolls by default (enroll: true), so a newly registered ticket is selected immediately; createSelection turns it off and applies its own multiple-aware logic.
Why it exists: adding an item to the store and marking it active are different actions that are easy to conflate. Naming the auto-select behavior separately keeps “in the registry” and “currently selected” as independent states.
See createModel.
Models and selection
Model
The value layer, created with createModel. It extends a registry with a reactive Set of selected ids plus the multiple and enroll options, and is the shared base for both selection and slider state.
Why it exists: “what value(s) are held” is a concern separate from “what selection rules apply.” Factoring the value store into createModel lets createSelection (rules) and createSlider (per-thumb math) reuse the same value plumbing.
See createModel and Core.
Selection
The selection-logic layer on top of a model, created with createSelection: it adds mandatory enforcement, disabled guards, and multi-select. Its specializations are createSingle (one at a time), createGroup (tri-state batches), createStep (next/prev navigation), and createNested (trees).
Why it exists: most interactive widgets — tabs, radios, checkboxes, wizards, treeviews — are selection problems. Layering the rules above the value store lets you pick the specialization that matches the widget and inherit the rest.
See createSelection and Core.