When to Use Global vs Local State
Apply the principle of colocation: keep state as close to its consumer as possible, and lift it only when multiple unrelated components need it.
When to Use Global vs Local State is a free Frontend Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Frontend Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The State Location Question
Every piece of state has an optimal home. Choosing the wrong location leads to either prop drilling pain or unnecessary global state complexity. The guiding principle: keep state as close to its consumers as possible.
Local Component State
If only one component uses the state, it belongs in that component's useState/ref. No sharing needed — keep it local. This is the simplest and most common case.
// Good: UI state local to the component
function Accordion() {
const [isOpen, setIsOpen] = useState(false); // only this component cares
return (
<div>
<button onClick={() => setIsOpen(o => !o)}>Toggle</button>
{isOpen && <div>Content</div>}
</div>
);
}Lifting State Up
When two sibling components need the same state, lift it to their closest common ancestor. Pass it down as props and callbacks. This is standard React/Vue before reaching for a global store.
Shared Context — Mid-level Sharing
When state needs to be shared across a subtree without prop drilling, Context (React) or provide/inject (Vue) is the right tool. This is for moderate-scope sharing (a page, a feature module).
Global Store — Application-Wide State
Use a global store (Redux, Zustand, Pinia) for state that: 1) is accessed by many unrelated components, 2) needs to survive navigation, 3) has complex update logic, 4) benefits from DevTools inspection.
Examples: Local State
Local state is right for: form field values, tooltip open/closed, modal visibility, hover state, animation state, loading indicators local to one component.
Examples: Lifted State
Lifted state is right for: a shared filter that two sibling lists use, the selected tab in a tab group, form data shared between two steps.
Examples: Context / Provide
Context is right for: current theme, authenticated user, locale/language, feature flags, notification stack — things consumed at many depths but updated infrequently.
Examples: Global Store
Global store is right for: shopping cart, authentication tokens + user object, notification queue (messages appear in a toast from anywhere), real-time data that multiple views display simultaneously.
Server State vs Client State
Network data (fetched from an API) is a special category: server state. It needs loading/error handling, caching, and invalidation. React Query / SWR / TanStack Query manage server state so your store can focus on true client state.
Common Mistake: Everything in the Global Store
Don't put all state in the global store 'just in case'. Local state is cheaper, simpler, and easier to test. Overusing global state creates coupling between components that should be independent.
Decision Framework
Ask: 1) Do other components need this? No → local. 2) Do close siblings need it? Yes → lift up. 3) Do a subtree of components need it? Yes → context/provide. 4) Do many unrelated components need it, or does it need DevTools? Yes → global store.
Quick Check
Where should you store the open/closed state of a single accordion component?
Recap: State Location
Principle: keep state as close to consumers as possible. Local useState/ref for single-component state. Lift up for sibling sharing. Context/provide for subtree sharing. Global store for application-wide state with complex updates. Server state (API data) belongs in React Query/SWR, not the global store.
Frequently asked questions
Is the “When to Use Global vs Local State” lesson free?
Yes — the full text of “When to Use Global vs Local State” is free to read here on the web, and the Frontend Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Frontend Academy course, upgrade to CoddyKit PRO.
What will I learn in “When to Use Global vs Local State”?
Apply the principle of colocation: keep state as close to its consumer as possible, and lift it only when multiple unrelated components need it. You practise Frontend Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Frontend Academy?
No prior experience is required. Frontend Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “When to Use Global vs Local State” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Frontend Academy lesson?
Yes. Every Frontend Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Redux Toolkit: createSlice and configureStore
- Zustand for Lightweight React State
- Pinia for Vue: defineStore and storeToRefs
- When to Use Global vs Local State