useProxyRegistry

useProxyRegistry listens for register and unregister events to know when to update reactive properties. Without events, the registry operates silently:

// Without events - proxy never updates
const registry = createRegistry()
const proxy = useProxyRegistry(registry)
registry.register({ value: 'item' })
console.log(proxy.size) // 0 - stale!

// With events - proxy stays in sync
const registry = createRegistry({ events: true })
const proxy = useProxyRegistry(registry)
registry.register({ value: 'item' })
console.log(proxy.size) // 1 - correct

Events add minimal overhead but aren’t enabled by default since many use cases don’t need reactivity. See createRegistry for the full events API.

Two costs to consider:

The proxy adds one event listener and updates refs on mutations. For most apps, this is insignificant. If you’re registering thousands of items per second, benchmark your specific case.

All read properties from the underlying registry:

Mutations (register, unregister, move) are called on the underlying registry instance — not through the proxy. The proxy automatically syncs via registry events.

Vue’s reactivity is granular. Components only re-render when they access properties that changed:

<template>
  <!-- Only re-renders when size changes -->
  <span>{{ proxy.size }} items</span>
</template>

<template>
  <!-- Re-renders when any item changes -->
  <div v-for="id in proxy.keys" :key="id">
    {{ proxy.get(id)?.value }}
  </div>
</template>

If you only read size, adding items triggers a re-render. If you iterate keys, any registration change triggers a re-render. Structure templates to minimize reactive dependencies.

reactive: true makes the internal collection a shallowReactive(new Map()), which looks like it should drive a v-for reactively — but there’s a subtle footgun.

values() caches its result internally and only invalidates when the collection mutates. Vue’s render effect clears all reactive dependencies on every run, then re-establishes them as reactive sources are read. If a re-render is triggered by something other than a collection mutation (e.g., a selection change), values() returns from cache without reading the underlying Map — so Vue never re-establishes the dep. The next time you add an item, Vue doesn’t know to re-render.

// Footgun: v-for may stop updating after a selection change
const single = createSingle({ reactive: true })
// After any selection-triggered re-render, addTab() won't update the list

useProxyRegistry avoids this entirely — it updates via events, not dep tracking:

// Safe: event-driven, no dep-tracking fragility
const single = createSingle({ events: true })
const proxy = useProxyRegistry(single)
// proxy.values always reflects current state

If you need reactive: true for ticket-level prop tracking, you can bypass the cache by reading single.collection.values() directly in the template — but useProxyRegistry is the recommended approach.

Yes. Selection composables extend createRegistry, so they work with useProxyRegistry if events are enabled:

import { createSelection, useProxyRegistry } from '@vuetify/v0'

const selection = createSelection({ events: true, multiple: true })
const proxy = useProxyRegistry(selection)

// Reactive access to registered items
proxy.size // Updates when items register/unregister

// Selection-specific state is still on the original
selection.selectedIds // Set of selected IDs

The proxy only exposes registry properties. For reactive selection state, use the selection instance directly or create a custom reactive wrapper.