Welcome back! From here on, we continue directly from "React for Beginners" – the same produktkatalog-web app, not a new project. If you're starting this series fresh: you need the final state of the 26 chapters from "React for Beginners" to follow along here.

produktkatalog-web/
├── index.html
├── package.json
├── vite.config.js
├── docker-compose.yml            (MySQL container for reviews)
├── server/                       (our own Node/Express server)
│   ├── package.json
│   ├── server.js
│   └── db.js
└── src/
    ├── main.jsx
    ├── App.jsx                   (routing)
    ├── index.css
    ├── api/
    │   ├── magentoApi.js         (Magento REST API: products)
    │   └── reviewsApi.js         (our own server: reviews)
    ├── context/
    │   └── AuthContext.jsx       (simple login state)
    ├── components/
    │   ├── ProductCard.jsx
    │   └── ProtectedRoute.jsx
    ├── hooks/
    │   └── useDocumentTitle.js   (custom hook)
    └── pages/
        ├── ProductListPage.jsx
        ├── ProductDetailPage.jsx
        ├── ReviewsPage.jsx       (nested route)
        ├── LoginPage.jsx
        └── AccountPage.jsx       (protected route)

What to expect in "React for Professionals"?

Five building blocks, each building on the last, applied directly to the existing project: state management (Zustand, Redux Toolkit – solving in practice the limits of Context this chapter uncovers), performance (the profiler, React.memo, list virtualization, concurrent features), internals (Virtual DOM, React Fiber, higher-order components, render props, portals, error boundaries), TypeScript integration (typing the existing project – the TypeScript language itself, every feature explained individually, is the subject of its own, separate tutorial), and testing/practice (Vitest, best practices, deployment, interview prep).

What the Context API is genuinely good at

Before talking about limits: AuthContext from "React for Beginners" was the RIGHT solution for its problem. Recall the "prop drilling" problem from chapter 11 – without Context, user/login/logout would need to be passed as props through EVERY intermediate component, including ones that don't use them at all. Context solves EXACTLY that: providing a value that ANY descendant component can read directly, no matter how deeply nested.

import { createContext, useContext, useState } from 'react';

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);

  function login(username) {
    setUser({ username });
  }

  function logout() {
    setUser(null);
  }

  return (
    <AuthContext.Provider value={{ user, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
}

export function useAuth() {
  const context = useContext(AuthContext);
  if (context === null) {
    throw new Error('useAuth() must be used inside <AuthProvider>.');
  }
  return context;
}

This is the final state from "React for Beginners" – shown as a reminder before we extend it in a moment to make a problem VISIBLE.

The real problem: EVERY consumer re-renders on EVERY change

Here's where it gets "professional"-relevant: <AuthContext.Provider value={{{{ user, login, logout }}}}> passes a NEW object literal as value on EVERY render of AuthProvider – even when user hasn't actually changed. React compares value by reference (===), not by "did the content change". If the reference changes, ALL components that call useContext(AuthContext) anywhere re-render – even ones that only read user and never use login/logout. Context has no concept of "partial subscriptions" – you get either the ENTIRE value or nothing.

Making the problem visible: a render counter

Talking is good, SEEING is better. We'll build a small, reusable RenderCounter that logs how often a component actually re-renders – a tool we'll reuse throughout this "for professionals" tutorial.

import { useRef } from 'react';

// A debug tool: shows how many times the parent component has re-rendered
// since the first render. useRef instead of useState is a deliberate choice -
// a useState update would itself trigger an extra render and skew the count;
// useRef counts "on the side" without causing re-renders of its own.
function RenderCounter({ label }) {
  const renderCount = useRef(0);
  renderCount.current += 1;

  return (
    <small style={{ opacity: 0.6 }}>
      ???? {label}: rendered {renderCount.current}×
    </small>
  );
}

export default RenderCounter;

Important: renderCount.current += 1 sits DIRECTLY in the function body, not inside a useEffect. That's deliberate – we want to count EVERY render, including ones that don't trigger side effects. useEffect would only run after COMMIT, which would be an unnecessary delay for this debug purpose.

Proving it: unrelated state in AuthContext

Now let's extend AuthContext, as an experiment, with a notification counter that has NOTHING to do with login/logout – purely to prove what happens:

import { createContext, useContext, useState } from 'react';

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [notificationCount, setNotificationCount] = useState(0); // unrelated state - demo purposes only

  function login(username) {
    setUser({ username });
  }

  function logout() {
    setUser(null);
  }

  function addNotification() {
    setNotificationCount((count) => count + 1);
  }

  return (
    <AuthContext.Provider value={{ user, login, logout, notificationCount, addNotification }}>
      {children}
    </AuthContext.Provider>
  );
}

export function useAuth() {
  const context = useContext(AuthContext);
  if (context === null) {
    throw new Error('useAuth() must be used inside <AuthProvider>.');
  }
  return context;
}

import { lazy, Suspense } from 'react';
import { Routes, Route } from 'react-router-dom';
import { useAuth } from './context/AuthContext';
import { useDocumentTitle } from './hooks/useDocumentTitle';
import RenderCounter from './components/RenderCounter';
import ProductListPage from './pages/ProductListPage';
import ProductDetailPage from './pages/ProductDetailPage';
import ProtectedRoute from './components/ProtectedRoute';

const ReviewsPage = lazy(() => import('./pages/ReviewsPage'));
const LoginPage = lazy(() => import('./pages/LoginPage'));
const AccountPage = lazy(() => import('./pages/AccountPage'));

function App() {
  const { user, login, logout, notificationCount, addNotification } = useAuth();
  useDocumentTitle('Product Catalog');

  return (
    <div className="app">
      <header className="app-header">
        <h1>Product Catalog</h1>
        <RenderCounter label="App header" />
        {user ? (
          <p>Logged in as {user.username} <button onClick={logout}>Log out</button></p>
        ) : (
          <button onClick={() => login('Jane Doe')}>Log in</button>
        )}
        <button onClick={addNotification}>
          ???? Notifications: {notificationCount} (click to increase)
        </button>
      </header>

      <Suspense fallback={<p>Loading page...</p>}>
        <Routes>
          <Route path="/" element={<ProductListPage />} />
          <Route path="/products/:sku" element={<ProductDetailPage />}>
            <Route path="reviews" element={<ReviewsPage />} />
          </Route>
          <Route path="/login" element={<LoginPage />} />
          <Route
            path="/account"
            element={
              <ProtectedRoute>
                <AccountPage />
              </ProtectedRoute>
            }
          />
        </Routes>
      </Suspense>
    </div>
  );
}

export default App;

Start the app (npm run dev) and click the "???? Notifications" button several times. RenderCounter counts up on EVERY click – even though App isn't "interested" in notificationCount beyond displaying it, and even though user never changes even once in the process. The reason: App calls useAuth(), and useAuth() returns the ENTIRE context value – React has no way of knowing that App "really" only cares about user/login/logout and could ignore notificationCount.

Why this becomes a real problem in real apps

In our small demo app, an extra render of App is harmless – the component is small, re-rendering costs microseconds. But the problem scales BADLY: imagine a context that bundles cart, notifications, theme, AND login status (a tempting but dangerous "one context for everything" approach), with HUNDREDS of components somewhere in the tree reading from it. Every cart change would then re-render EVERY one of those hundred components – even one that just displays the current language.

Cleaning up the demo

The notifications button was purely illustrative – before moving on, remove it again from AuthContext.jsx and App.jsx, restoring the state from "React for Beginners" (you can do this yourself now: just remove notificationCount/addNotification from both files; RenderCounter stays as a useful debug tool for the coming chapters). We'll solve the real, CLEAN problem structurally in the next chapter: replacing AuthContext with Zustand, a small state management library where components subscribe precisely to only the values they actually need.