Master Table of Contents

• See full index in [01. Introduction]

Who this chapter is for

• Learners whose app is growing and state starts feeling chaotic
• Beginners who keep passing props through too many component layers
• Anyone wondering: “Do I need Context, Zustand, or Redux right now?”

What you’ll learn

• How to decide when local state is still enough
• How to use Context API for shared app values
• Practical criteria for when to introduce Zustand or Redux

Why this topic matters

State architecture is one of the biggest make-or-break parts of React apps.

If state is scoped well, features are easier to add and bugs are easier to isolate. If state is scattered or over-centralized, everything feels harder than it should.

Core concepts

Prop drilling

• Passing props through many layers to reach deep children
• Can reduce readability at scale

Prop drilling is not always bad. It becomes a problem when intermediate components only forward props and do nothing else.

Context API

• Provides shared values without deep prop chains
• Good for theme, auth, and app settings

Context is best for app-wide values that many components consume.

Store libraries

• Useful when state interactions become complex
• Introduce only when needed

Store libraries help when updates are frequent, cross-feature, and hard to reason about.

Step-by-step walkthrough

Step 1 — Identify shared state candidates

List states by scope:

• local page state,
• feature-level shared state,
• app-wide state (theme/auth/preferences).

Step 2 — Implement Context provider

Create provider + custom hook for one concern first (example: theme).

Keep it focused before adding more responsibilities.

Step 3 — Evaluate scaling needs

If Context starts causing large rerenders or complex update flows, evaluate a store library.

Rule: escalate tools only when current complexity justifies it.

Practical examples

Example 1 — Context shape

type ThemeContextValue = {
  theme: "light" | "dark";
  toggleTheme: () => void;
};

Tip:

• Keep context value shape small and explicit.

Example 2 — Provider usage concept

• Wrap app root with provider
• Consume via custom hook in child components

Pattern to keep code clean:

• export both ThemeProvider and useTheme() from one module.

Common mistakes and how to avoid them

• Putting all state into Context -> keep local state local
• Triggering wide rerenders on tiny updates -> split contexts by concern
• Choosing Redux because of hype -> solve current complexity first
• No state ownership rules -> define who owns and updates each state domain

Mini Project

• Build a small app-wide state setup with:
• theme toggle,
• auth-like user session,
• one local state example that stays outside Context.

Bonus:

• Measure rerender behavior and split context if needed.

Quick practice

• Refactor one prop-drilling flow to Context
• Split one large context into two focused contexts
• Document when you would switch to store library
• Write one “state scope decision” note for your current project

Key takeaways

• State scope decisions should be explicit, not accidental
• Context is powerful for many beginner-to-intermediate global needs
• Add store libraries when complexity is real, not because it sounds advanced

Next step

Continue to [14. API Integration Patterns]