Sharing State Across Components
As an application grows past a handful of components, keeping every piece of state local becomes untenable — sibling components need to react to each other's changes, deeply nested children need data from a distant ancestor, and unrelated parts of the UI (a cart icon in the header, a checkout page) need to read the same source of truth. Vue offers a layered set of tools for this rather than a single one-size-fits-all mechanism, and picking the right layer for the right distance and lifetime of sharing is a core architectural skill.
Cricket analogy: As a tournament grows past a single match, you need more than one team's scorebook — the head office scoreboard, individual team dressing rooms, and the broadcast graphics team all need to read the same live score, and choosing the right channel (radio, sideline signal, or central feed) for each is a real coordination skill.
Props Down, Events Up (Local, Parent-Child)
For directly related parent-child pairs, plain props and emitted events remain the simplest and most explicit mechanism — the parent owns the state and passes it down as a prop, the child requests a change by emitting an event, and the parent decides how to update its own state in response. This unidirectional flow is easy to trace and test because the state has exactly one owner. The tradeoff is that it does not scale well through many layers: passing a prop through three or four intermediate components that don't themselves use it — known as 'prop drilling' — adds noise and coupling to components that shouldn't care about that data.
Cricket analogy: For a captain and a specific bowler, a direct hand signal (props) and the bowler's shout back (emit) is the simplest, clearest system — one owner, easy to trace — but relaying that signal through three fielders who don't need it themselves is the prop-drilling problem in the field.
Provide/Inject for Deep Trees
provide() and inject() solve prop drilling by letting an ancestor make a value available to any descendant, no matter how deeply nested, without every intermediate component declaring a prop for it. This is ideal for things like a theme object, a form-validation context, or a design-system component's shared configuration — data that is conceptually 'ambient' to a subtree rather than passed explicitly at each level. Provide/inject is not reactive-safe by accident, though: you must provide a ref or reactive object (not a raw primitive) for injected consumers to receive updates.
Cricket analogy: A tournament's DRS review-count rule is "ambient" to the whole ground rather than passed match by match — provide/inject lets the governing body broadcast it to any umpire, however deep in the fixture list, but only if the rule is a live reactive object, not a printed static number that never updates.
<!-- AncestorProvider.vue -->
<script setup>
import { provide, ref } from 'vue'
const wizardStep = ref(1)
function goToStep(n) {
wizardStep.value = n
}
provide('wizard', { wizardStep, goToStep })
</script>
<template>
<slot />
</template>
<!-- DeeplyNestedChild.vue -->
<script setup>
import { inject } from 'vue'
const { wizardStep, goToStep } = inject('wizard')
</script>
<template>
<p>Step {{ wizardStep }}</p>
<button @click="goToStep(wizardStep + 1)">Next</button>
</template>Composables for Shared Logic and State
A composable — a function starting with use that returns reactive refs and functions — can hold state outside any single component's setup() scope. If you declare the reactive state at module scope (outside the composable function body) rather than inside it, every component that calls the composable shares the same underlying state, making it a lightweight singleton store without pulling in a state-management library at all. This pattern works well for small, focused pieces of shared state such as a useAuthUser() composable, but it lacks the devtools integration, SSR-safety guarantees, and structured actions/getters that a dedicated store library provides.
Cricket analogy: A "useMatchClock" function declared at module scope, outside any single umpire's individual watch, means every umpire on the ground shares the exact same running clock — great for a simple shared timer, but it lacks the official scoreboard's replay logging, backup power, and structured review process a full match-control system provides.
React's closest analogues are Context (comparable to provide/inject) and a global store like Redux or Zustand (comparable to Pinia). Vue's composables occupy a middle ground with no direct React equivalent — a custom hook in React does not share state across call sites unless you explicitly hoist that state to a module or context.
Pinia for Global, App-Wide State
When state needs to be accessed from many unrelated parts of the app, persisted, time-travel debugged, or organized into clearly named domains (useCartStore, useAuthStore), Pinia is the right tool. It provides a single source of truth with devtools support, SSR hydration handling, and a conventional structure (state/getters/actions) that keeps large applications navigable. Reach for Pinia when the same state is read or written from components with no direct ancestor-descendant relationship and no shared parent that could reasonably own it.
Cricket analogy: When match data needs to reach the scoreboard, the broadcast graphics, the stats team, and the post-match report — all unrelated parts of the operation with no shared "parent" screen — a centralized system like Pinia (organized into useMatchStore, useTeamStore) with full audit history and replay capability is the right tool, not ad hoc signals between booths.
Overusing provide/inject for state that changes frequently and is consumed widely can make data flow hard to trace, since any ancestor in the tree could theoretically be the provider. If more than two or three unrelated component subtrees need the same state, that's usually a signal to move it into a Pinia store instead.
- Props/emits are best for direct parent-child communication with a single, clear state owner.
- provide/inject avoids prop drilling for deeply nested descendants but requires providing refs/reactive objects to stay reactive.
- Module-scoped composables can act as lightweight shared stores without a state-management library.
- Pinia is the right choice for state accessed by many unrelated components, or needing devtools/SSR support.
- Choosing the wrong layer (e.g. provide/inject for truly global state) makes data flow hard to trace as an app grows.
- These tools are complementary, not mutually exclusive — most real apps use props locally and Pinia globally.
Practice what you learned
1. What problem does provide/inject primarily solve compared to plain props?
2. For an injected value to update reactively when the provider's data changes, what must be provided?
3. How can a composable function create shared (not per-instance) state across multiple components?
4. Which scenario most strongly suggests reaching for Pinia over provide/inject?
5. What is a key risk of overusing provide/inject for frequently changing, widely consumed state?
Was this page helpful?
You May Also Like
Pinia Basics
Get started with Pinia, Vue's official state management library, covering stores, state, and how components read and mutate shared data.
provide and inject
Understand Vue's dependency-injection mechanism for passing data deep through a component tree without prop drilling.
Composables Explained
Understand what composables are, why they replace mixins as Vue's primary reuse pattern, and the conventions they follow.
Props Explained
Explains how props pass data from parent to child components in Vue, covering declaration, validation, defaults, and the one-way data flow rule.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics