The Smart Way to Share State —Master useContext in React

The Prop Drilling Problem Every React Developer Hits

Welcome back to Let’s Master React Hooks Together — the series where we learn React Hooks the practical way, like real-world developers actually use them.

In the previous episodes, we explored hooks like useState, useEffect and useNavigate . But now we’re entering a stage where React apps start becoming real applications — with shared state, nested components, themes, authentication, and global UI behavior.

And that’s exactly where developers hit one frustrating problem:

prop drilling.

You create a piece of state in a parent component, but suddenly you’re passing it through 4 or 5 layers of components just so one deeply nested child can use it.

Your component tree starts looking like this:

App → Layout → Header → Navbar → Button

And somewhere deep inside that tree, a button just needs the current theme or logged-in user.

The result?

• messy props
• unnecessary component coupling
• harder maintenance
• painful refactoring

React introduced the Context API to solve this problem.

And later, hooks made it dramatically cleaner with useContext.

In this episode, we’ll learn:

• what useContext is
• why React introduced it
• how it works mentally
• when to use it
• when NOT to use it
• performance pitfalls developers often miss

Let’s master it properly.

---

The Problem: Prop Drilling in React

Imagine you want to pass theme and user data to a deeply nested component.

function App() {
  return <Layout theme="dark" user={user} />;
}

function Layout({ theme, user }) {
  return <Header theme={theme} user={user} />;
}

function Header({ theme, user }) {
  return <Navbar theme={theme} user={user} />;
}

function Navbar({ theme, user }) {
  return <Button theme={theme} user={user} />;
}

Notice the issue?

Layout, Header, and Navbar may not even care about theme or user.

They’re just forwarding props downward.

This creates unnecessary complexity:

• components become harder to read
• props explode over time
• refactoring becomes risky
• maintenance gets annoying

Mentally, it looks like this:

App → Layout → Header → Navbar → Button → Theme

As applications grow, this pattern becomes difficult to manage.

React needed a cleaner way for components to access shared data directly.

That’s where Context comes in.

---

What is Context API?

The Context API is React’s built-in shared state mechanism.

It allows components to access common data without manually passing props through every level.

Think of it like a WiFi router.

Any device inside the network can access the internet without needing a direct cable connection to the source.

Similarly, components inside a Context Provider can access shared data directly.

React Context mainly consists of 3 parts:

1. Create Context

const ThemeContext = createContext();

2. Provider

<ThemeContext.Provider value={theme}>

3. Consumer (useContext)

const theme = useContext(ThemeContext);

That’s the core idea.

Simple concept. Massive improvement in component architecture.

---

What is useContext?

useContext is a React Hook that lets a component read data from a Context.

const value = useContext(MyContext);

In simple words:

“Give me the nearest value from this context.”

Before hooks existed, developers used Context.Consumer, which quickly became deeply nested and difficult to read.

Hooks made Context usage much cleaner and more natural.

Slightly Technical Understanding

When React renders a component using useContext, it searches upward through the component tree for the nearest matching Provider.

If the Provider value changes, React re-renders the components consuming that context.

That’s the main mental model.

---

Real Example: Theme Switching

Let’s build a simple dark/light theme system.

Create Context

import { createContext, useState } from "react";

export const ThemeContext = createContext();

Create Provider

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState("light");

  const toggleTheme = () => {
    setTheme(prev => (prev === "light" ? "dark" : "light"));
  };

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

Consume Context

import { useContext } from "react";
import { ThemeContext } from "./ThemeContext";

function Button() {
  const { theme, toggleTheme } = useContext(ThemeContext);

  return (
    <button onClick={toggleTheme}>
      Current theme: {theme}
    </button>
  );
}

Now any component inside ThemeProvider can directly access the theme.

No prop drilling.

No unnecessary intermediary props.

Cleaner architecture.

---

How useContext Works (Mental Model)

Here’s the simplest mental model:

When React sees this:

useContext(ThemeContext)

it walks upward through the component tree searching for:

<ThemeContext.Provider>

The nearest provider wins.

Think of it like searching for the nearest WiFi signal.

If the Provider value changes:

value={newValue}

React re-renders components consuming that context.

That re-render behavior is important for performance.

---

When to Use useContext

useContext works best for shared application-wide state.

Great use cases include:

• theme systems
• authenticated user data
• language switching
• sidebar visibility
• app settings
• cart information

A simple rule:

If many distant components need the same data, Context is usually a good fit.

---

When NOT to Use useContext

This is where many developers misuse Context.

Avoid Frequently Changing State

Examples:

• typing inputs
• mouse movement
• animations
• rapidly updating values

Why?

Because every context update can trigger many component re-renders.

Avoid Replacing Local State

If only one component needs the state, useState is usually better.

Not everything belongs in global state.

Overusing Context creates bloated architectures that become difficult to maintain.

---

Performance Concerns (Important)

Here’s a very common mistake:

<Provider value={{ user, setUser }}>

Why is this problematic?

Because a new object is created on every render.

React compares references, not deep values:

{} !== {}

So all consuming components re-render.

Even if user didn’t actually change.

Better Approach

Memoize the value:

const value = useMemo(() => ({ user, setUser }), [user]);

Another important optimization:

Split Contexts by Concern

Instead of one massive global context:

AppContext

prefer smaller focused contexts:

ThemeContext
AuthContext
LanguageContext

This reduces unnecessary re-renders and improves maintainability.

---

Best Practices

Keep Context Small

Focused contexts are easier to manage.

Split by Responsibility

Separate auth, theme, language, cart, etc.

Avoid Giant Global Contexts

Large contexts become difficult to debug and optimize.

Keep Provider Values Stable

Memoize objects and functions when necessary.

Use Custom Hooks

Cleaner API:

const theme = useTheme();

instead of repeatedly calling useContext.

---

Real-World Examples

Authentication System

Store logged-in user data globally so navbar, dashboard, and profile pages can access it instantly.

Theme System

Dark/light mode is one of the best examples of Context usage.

Language Switcher

Allow the entire application to switch languages consistently.

Shopping Cart

E-commerce apps often share cart count and cart items across many components.

---

Interview Questions (Quick Revision)

What is useContext?

A hook that allows components to consume values from React Context.

What problem does it solve?

Prop drilling.

Does useContext replace Redux?

No. Context helps with shared state, but Redux handles more advanced global state patterns.

Why do consumers re-render?

Because the Provider value changes.

When should you avoid Context?

For fast-changing or highly local component state.

What does “nearest provider wins” mean?

React uses the closest matching Provider above the component in the tree.

---

Final Summary

In Episode 5 of Let’s Master React Hooks Together, we learned that useContext exists to solve one major React problem:

prop drilling.

It allows components to access shared state directly without passing props through every layer.

Use it for:

• themes
• authentication
• language settings
• shared UI state

Avoid it for:

• rapidly changing values
• highly local state
• giant global stores

And most importantly:

Context is powerful, but every update can trigger re-renders.

Use it thoughtfully, keep contexts focused, and your React architecture will stay clean and scalable.

In the next episode of Let’s Master React Hooks Together, we’ll explore one of React’s most misunderstood hooks:

useRef — how React remembers values without causing re-renders.