Vue Provide / Inject

Share data across a component tree without prop-drilling using provide/inject

When to Use

• A parent component needs to share data with deeply nested descendants
• You want to avoid passing props through intermediate components that do not use them
• Implementing theme, locale, or configuration providers at the app level

Instructions

1. In the ancestor component, call

   provide(key, value)

   inside

   <script setup>

   .
2. In any descendant, call

   const value = inject(key)

   to receive the provided value.
3. Use

   InjectionKey<T>

   for type-safe provide/inject in TypeScript.
4. Provide reactive values (

   ref

   or

   reactive

   ) so descendants receive live updates.
5. Always provide a default value or document that

   inject()

   may return

   undefined

   .

// Parent — provides theme
import { provide, ref } from 'vue';
const theme = ref('light');
provide('theme', theme);

// Deep child — injects theme
import { inject } from 'vue';
const theme = inject('theme', ref('light'));

6. Use Symbol keys to avoid naming collisions between providers.

Details

Vue's

provide

/

inject

is a dependency injection mechanism scoped to the component tree. A provider makes a value available to all its descendants, regardless of depth. Unlike props, the intermediate components do not need to know about or forward the value.

Trade-offs:

• Implicit dependencies — it is not obvious from a component's props what injected values it depends on
• Debugging is harder — there is no props panel in DevTools for injected values (though Vue DevTools does show provide/inject)
• Overuse leads to "spooky action at a distance" — changes in a provider affect distant descendants

When NOT to use:

• When only one level of nesting exists — just pass a prop
• For application-wide global state — use Pinia stores instead
• When multiple providers might conflict — the closest ancestor's provide wins, which can be confusing

Source

https://patterns.dev/vue/provide-inject

Process

1. Read the instructions and examples in this document.
2. Apply the patterns to your implementation, adapting to your specific context.
3. Verify your implementation against the details and edge cases listed above.

Harness Integration

• Type: knowledge — this skill is a reference document, not a procedural workflow.
• No tools or state — consumed as context by other skills and agents.

Success Criteria

• The patterns described in this document are applied correctly in the implementation.
• Edge cases and anti-patterns listed in this document are avoided.