🏠
🏠 Home / 05-part-v-real-world-case-studies

7.14 Case Study 2: React Component Render Chain

The Setup: Your team's React dashboard shows a user profile panel that displays basic info: name, email, last login time. Users complain the page feels sluggish. You open the app and it seems fine, but when you open Chrome DevTools and check the Console, you see:

[Component UserProfile] rendered

[Component UserProfile] rendered

[Component UserProfile] rendered

...

[Component UserProfile] rendered  (× 50 times in 2 seconds)

Someone added console.log statements during debugging and never removed them. Now you see the problem: UserProfile re-renders 50 times on initial page load. Why?

The initial confusion: You examine the component code:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser(userId).then((data) => setUser(data));
  }, [userId]);

  if (!user) return <div>Loading...</div>;

  return (
    <div className="profile">
      <h2>{user.name}</h2>

      <p>{user.email}</p>

      <LastLoginTime timestamp={user.lastLogin} />
    </div>
  );
}

This looks reasonable. The useEffect has userId as a dependency, so it should only run when userId changes. What's causing 50 re-renders?

You try adding more console.log statements to track down the issue:

function UserProfile({ userId }) {
  console.log("UserProfile render, userId:", userId);

  const [user, setUser] = useState(null);

  console.log("user state:", user);

  useEffect(() => {
    console.log("useEffect running");

    fetchUser(userId).then((data) => {
      console.log("fetchUser returned:", data);

      setUser(data);
    });
  }, [userId]);

  console.log("about to return JSX");

  // ...
}

Now your console is flooded with logs, making it hard to understand the sequence. You see useEffect running printed 50 times, which means... userId is changing 50 times? But you passed it from props and the parent component shouldn't be changing it.

After two hours of adding logs to the parent component, the grandparent, and various child components, you're drowning in console output with no clear picture of what's causing the cascade.

This is console.log hell: when debugging state becomes harder than solving the original problem.

Problem: Why does this component re-render 50 times?

Let's start over with the right tools and solve this in 20 minutes.

Phase 1: Install React DevTools (if not already installed)

Open Chrome, go to the Extensions page (chrome://extensions/), search for "React DevTools" in the Chrome Web Store, and install it. After installation, you'll see a new "React" tab in Chrome DevTools.

Phase 2: Use the React Profiler (5 minutes)

Open your dashboard app and open Chrome DevTools. Click the "Profiler" tab within the React DevTools panel (not the Chrome "Performance" tab—that comes later).

Click the blue "Record" button, then reload the page to trigger the 50 re-renders. After 2-3 seconds, click "Stop profiling".

What you see: A flame graph showing every component render during that recording session. The graph has a timeline scrubber at the bottom. Drag it to see render activity over time.

You immediately notice something striking: UserProfile appears 50 times in the flame chart, but so does its parent component DashboardMain. In fact, DashboardMain renders 50 times, and every time it renders, it causes UserProfile to render.

Click on one of the DashboardMain render bars. The right panel shows:

DashboardMain (8.2ms)

  Why did this render?

  - State changed: currentView



Props changed:

  - userId: Object {} (previous) → Object {} (new)

This is the key insight: userId is shown as a prop that "changed", but notice it's an object both times. Click to expand the object and you see:

Previous: { id: 123, name: "John" }

New:      { id: 123, name: "John" }

The values are identical, but React thinks the prop changed because it's a new object instance with each render. JavaScript object comparison works by reference, not by value:

{ id: 123 } === { id: 123 }  // false - different object instances

Now check DashboardMain's code to see where userId prop comes from:

function DashboardMain() {
  const [currentView, setCurrentView] = useState("profile");

  const [userData, setUserData] = useState(null);

  useEffect(() => {
    fetchDashboardData().then((data) => setUserData(data));
  }, []);

  // The problem is here:

  const userId = { id: userData?.id, name: userData?.name };

  return (
    <div>
      <ViewSelector current={currentView} onChange={setCurrentView} />

      <UserProfile userId={userId} />
    </div>
  );
}

Found it! Every time DashboardMain renders (for any reason), it creates a new userId object. Even though the values inside are the same, React sees a different object reference and re-renders UserProfile.

But why does DashboardMain render 50 times? Look at the ViewSelector component:

function ViewSelector({ current, onChange }) {
  const views = ["profile", "settings", "activity"];

  useEffect(() => {
    // Animate the current view highlight

    const interval = setInterval(() => {
      // ... animation logic that updates internal state
    }, 50); // Runs every 50ms

    return () => clearInterval(interval);
  }, [current]);

  // ...
}

Ah! ViewSelector has an animation that updates its own internal state every 50 milliseconds. Since ViewSelector is a child of DashboardMain, and React's default behavior is to re-render parent components when children update... wait, that's backwards.

Actually, let's verify this in React DevTools. Click on a different DashboardMain render in the Profiler. It shows:

Why did this render?

- State changed: currentView

The state currentView is changing, but looking at the code, nothing calls setCurrentView in this flow. Click on the ViewSelector component in the React DevTools Components tab (not Profiler, the other tab). Select the ViewSelector instance and inspect its props.

You see onChange={setCurrentView}, and looking more carefully at the ViewSelector code:

useEffect(() => {
  const interval = setInterval(() => {
    // Animation logic

    updateHighlightPosition();

    // Bug: This was intended for debugging but calls onChange accidentally

    onChange(current); // <-- This triggers setCurrentView() in parent!
  }, 50);

  return () => clearInterval(interval);
}, [current, onChange]);

The complete picture emerges:

  1. ViewSelector runs an animation interval every 50ms

  2. The interval callback calls onChange(current) (a leftover debugging line)

  3. onChange is setCurrentView, so this updates state in DashboardMain

  4. DashboardMain re-renders because currentView state changed (even though it's the same value)

  5. DashboardMain creates a new userId object during render

  6. UserProfile receives the new userId object and re-renders

  7. This cycle repeats every 50ms → 50 renders in 2.5 seconds

Phase 3: Validate with Chrome Performance Tab (5 minutes)

To confirm the timing and see the performance impact, use Chrome's built-in Performance profiler:

  1. Open the Chrome DevTools "Performance" tab (not React's Profiler)

  2. Click the record button (circle icon)

  3. Reload the page

  4. Stop recording after 3 seconds

You see a timeline with:

Zoom into the first 3 seconds. You see repeating spikes of yellow (scripting) every 50ms, each spike labeled with "Timer Fired" → "React work" → "UserProfile render".

This confirms: the timer callback triggers React reconciliation 50 times, and each reconciliation causes UserProfile to re-render even though its content doesn't change.

The Performance tab also shows the wasted work: each render cycle recalculates component trees, runs diffing, and updates the virtual DOM even though the final output to the real DOM is identical.

Tools used: React DevTools Profiler + Chrome Performance tab

React DevTools Profiler gave you:

  1. Visual render timeline: See every component render as it happens

  2. Why did this render explanation: React tells you exactly what changed (state, props, context)

  3. Props comparison: See old vs new props side-by-side, revealing the object reference issue

  4. Component hierarchy: Understand parent-child relationships and render cascades

  5. Render duration: See which renders are expensive (8.2ms for DashboardMain) vs cheap

Chrome Performance tab gave you:

  1. Timing validation: Confirm renders happen every 50ms, matching the interval

  2. Performance impact measurement: Quantify the cost of unnecessary renders

  3. Call stack visualization: See the exact sequence: Timer → interval callback → setState → React reconciliation → component render

  4. Resource usage: CPU and memory spikes caused by the render thrashing

Why this beats console.log debugging:

With console.logs, you saw:

UserProfile render, userId: Object

user state: null

useEffect running

fetchUser returned: Object

UserProfile render, userId: Object

user state: Object

about to return JSX

UserProfile render, userId: Object

user state: Object

...

This textual output doesn't show you:

React DevTools shows all of this visually and interactively. You scrub through the timeline, click renders to see details, and compare prop values—all without modifying any code.

Discovery: Parent component state thrashing

Let's understand what "state thrashing" means and why it's a common React antipattern.

State thrashing occurs when a component updates state frequently with the same value, causing re-renders even though nothing changed. In this case:

setCurrentView("profile"); // State: 'profile'

setCurrentView("profile"); // State: 'profile' (same value!)

setCurrentView("profile"); // State: 'profile' (same value!)

// ... 47 more times

React doesn't bail out of these updates even though the value is identical. Why not? Because detecting value equality for all possible state types (objects, arrays, functions) is expensive and not always what developers want (sometimes you intentionally set state to the same value to trigger effects).

The cascading problem happens because:

  1. Parent re-renders due to state thrashing

  2. Parent creates new object references during render (the userId object)

  3. Children receive "new" props (by reference) even though values are identical

  4. Children re-render unnecessarily

Common causes of state thrashing:

The fix for this case study:

// Fix 1: Don't call onChange with the same value

useEffect(() => {
  const interval = setInterval(() => {
    updateHighlightPosition();

    // Remove this line entirely - it was for debugging

    // onChange(current);
  }, 50);

  return () => clearInterval(interval);
}, [current]); // Remove onChange from dependency array

// Fix 2: Memoize the userId object in DashboardMain

import { useMemo } from "react";

function DashboardMain() {
  const [currentView, setCurrentView] = useState("profile");

  const [userData, setUserData] = useState(null);

  // Only create new object when userData.id or userData.name actually changes

  const userId = useMemo(
    () => ({ id: userData?.id, name: userData?.name }),

    [userData?.id, userData?.name],
  );

  return (
    <div>
      <ViewSelector current={currentView} onChange={setCurrentView} />

      <UserProfile userId={userId} />
    </div>
  );
}

After applying both fixes:

Validation: Profile again with React DevTools. You see exactly 2 renders:

  1. Initial render (userData is null, showing "Loading...")

  2. Second render after fetchDashboardData() completes (userData loads, showing profile)

Performance improves dramatically. The Chrome Performance tab shows no repeated scripting spikes, just a single initial render cycle.

Time to diagnosis: 20 minutes

Time breakdown:

Total: 20 minutes from problem to complete understanding of the root cause.

Alternative attempted: console.log hell (abandoned after 2 hours)

Let's reflect on why the console.log approach failed so spectacularly.

What you tried:

// Added logs to UserProfile

console.log("UserProfile render, userId:", userId);

// Added logs to DashboardMain

console.log("DashboardMain render, currentView:", currentView);

// Added logs to ViewSelector

console.log("ViewSelector render");

console.log("ViewSelector effect running");

// Added logs to child components

console.log("LastLoginTime render");

// Added logs to useEffect dependencies

console.log("useEffect dependencies:", [userId]);

What happened: Your console filled with hundreds of lines:

DashboardMain render, currentView: profile

ViewSelector render

ViewSelector effect running

UserProfile render, userId: Object { id: 123, name: "John" }

useEffect dependencies: [Object]

LastLoginTime render

ViewSelector effect running

DashboardMain render, currentView: profile

UserProfile render, userId: Object { id: 123, name: "John" }

useEffect dependencies: [Object]

LastLoginTime render

... (×50)

Why this failed:

  1. Too much noise: 50 render cycles × 5 components × 2-3 logs per component = 500+ log lines

  2. No timing information: Logs don't show the 50ms interval timing

  3. Object comparison impossible: console.log('userId:', userId) shows Object but doesn't reveal that each is a new reference

  4. Cause-effect unclear: Which component triggered which re-render? The textual logs don't show parent-child relationships

  5. Performance cost: The logging itself adds overhead, making the problem worse and skewing your investigation

What you learned from trying: After 2 hours, you knew:

Contrast with React DevTools: In 20 minutes, you knew:

The lesson: console.log debugging is like trying to understand a movie by reading a transcript. React DevTools is like watching the movie with director's commentary, slow-motion replay, and a scene-by-scene breakdown. Both tell you the same story, but one makes comprehension vastly easier.

When console.log is appropriate:

When React DevTools wins:

This case study demonstrates that reaching for the right tool transforms impossible problems into trivial ones. The same problem that consumed 2 hours with console.log took 20 minutes with React DevTools—not because you became smarter, but because you used a tool designed specifically for the problem you were solving.

Generated on 2025-10-13 21:22:41 | Made with ❤️ by GitHub Pages Generator