My React App Froze on Every Keystroke. I Fixed It by Stealing Python's #1 Rule About Scope.

Last month I built a dashboard with about 150 components. A data table, a few charts, a sidebar, and a search bar. Nothing unusual.

Then I typed into the search bar.

The input lagged behind my fingers by almost 300 milliseconds. Every keystroke felt like I was fighting the UI. React DevTools told the story: a single keypress was triggering re-renders across the entire component tree. Components that had nothing to do with search were getting re-rendered on every character.

I spent an embarrassing amount of time looking for the right hook to fix this. useMemo? useCallback? React.memo on everything?

The actual fix had nothing to do with memoization. It came from a principle I internalized years ago while writing Python.

The Mistake Python Developers Never Make

If you have written Python for any length of time, you know the Zen of Python has a clear opinion about this:

"Namespaces are one honking great idea — let's do more of those!"

Python developers learn early: don't pollute the global scope. If a variable is only used inside one function, it belongs inside that function. You don't declare it at the module level and hope for the best. Why? Because mutating a global variable causes unpredictable side effects across your entire program.

React has the exact same problem. And I walked right into it.

Here was my code:

import { useState } from "react";



export default function Dashboard() {

  const [searchQuery, setSearchQuery] = useState("");



  return (

    <div className="layout">

      <Header />

      <Sidebar />

      <main>

        <SearchBar value={searchQuery} onChange={setSearchQuery} />

        <DataGrid query={searchQuery} />

        <HeavyCharts />

        <Footer />

      </main>

    </div>

  );

}

The searchQuery state lived at the top of Dashboard. That is the React equivalent of a Python global variable. And React enforces a simple rule: when a component's state changes, React re-renders that component and walks through its entire subtree.

That means every time I typed the letter "a", React re-evaluated Header, Sidebar, HeavyCharts, and Footer. None of them cared about the search query. But React didn't know that, because I placed the state too high up.

Here is what the React Profiler showed me:

Every component in the tree was lit up orange. Total render time per keystroke: 142.7ms. On a 60 FPS budget, that is catastrophic. The browser only has 16ms per frame. I was blowing past that by almost 9x.

The Fix: State Colocation

In React, this principle is called State Colocation: move state as close to where it's used as possible. It is the direct equivalent of Python's local variable scoping. Keep your variables where they belong. Don't let them leak upward.

I asked myself two questions:

1. Does the Header care about searchQuery? No.
   


2. Does the Sidebar care about searchQuery? No.
   

Only two components need it: SearchBar and DataGrid. So I wrapped them in their own small parent:

import { useState } from "react";



function SearchableDataGrid() {

  const [searchQuery, setSearchQuery] = useState("");



  return (

    <>

      <SearchBar value={searchQuery} onChange={setSearchQuery} />

      <DataGrid query={searchQuery} />

    </>

  );

}



export default function Dashboard() {

  return (

    <div className="layout">

      <Header />

      <Sidebar />

      <main>

        <SearchableDataGrid />

        <HeavyCharts />

        <Footer />

      </main>

    </div>

  );

}

Now when I type in the search bar, React only re-renders SearchableDataGrid and its two children. Header, Sidebar, HeavyCharts, and Footer are completely untouched.

Here is what the Profiler looked like after the change:

Total render time per keystroke dropped from 142.7ms to 4.1ms. The input lag vanished. No extra libraries. No memoization wrappers. Just moving state to where it actually belongs.

Visualizing the Blast Radius

This diagram shows the full picture. Before the fix, the entire tree re-renders. After the fix, only the isolated group updates:

And here is the isolated state view, zoomed in:

Why This Works (The React Rendering Rule)

React's rendering behavior follows one core rule:

When state changes inside a component, React re-renders that component and every component nested inside it.

It does not re-render siblings or parents. It walks downward through the subtree.

When searchQuery lived inside Dashboard, every child of Dashboard was part of the blast radius. When I moved it into SearchableDataGrid, the blast radius shrank to just two components.

Think of it like this:

BEFORE (state hoisted too high):

Dashboard [STATE HERE] ← every keystroke triggers

├── Header            ← re-renders (wasted)

├── Sidebar           ← re-renders (wasted)

├── SearchBar         ← re-renders (needed)

├── DataGrid          ← re-renders (needed)

├── HeavyCharts       ← re-renders (wasted)

└── Footer            ← re-renders (wasted)



AFTER (state colocated):

Dashboard             ← stable, no re-render

├── Header            ← stable

├── Sidebar           ← stable

├── SearchableDataGrid [STATE HERE] ← only this subtree updates

│   ├── SearchBar     ← re-renders (needed)

│   └── DataGrid      ← re-renders (needed)

├── HeavyCharts       ← stable

└── Footer            ← stable

When This Is Not Enough

State Colocation is powerful, but it is not a universal fix. Here is when you will need more:

1. When the DataGrid itself is expensive.

If your DataGrid filters 10,000 rows on every keystroke, colocating the state won't help because the real bottleneck is the filtering work, not the re-renders. In that case, reach for useDeferredValue or useTransition:

import { useState, useDeferredValue } from "react";



function SearchableDataGrid() {

  const [searchQuery, setSearchQuery] = useState("");

  const deferredQuery = useDeferredValue(searchQuery);



  return (

    <>

      <SearchBar value={searchQuery} onChange={setSearchQuery} />

      {/* DataGrid uses the deferred value, so the input stays responsive */}

      <DataGrid query={deferredQuery} />

    </>

  );

}

useDeferredValue tells React: "Keep the search input snappy. Update the heavy DataGrid when you have a free moment." This is built into React 18+ and costs zero extra dependencies.

2. When state genuinely needs to be shared across distant branches.

If your searchQuery suddenly needs to update a badge count in the Header, pushing state down will break. At that point, you need either:

• 
  useContext for simple cases


• A lightweight store like Zustand or Jotai for complex ones

3. When individual children are expensive on their own.

If HeavyCharts takes 80ms to render regardless of props, wrap it in React.memo:

const HeavyCharts = React.memo(function HeavyCharts() {

  // expensive chart rendering

});

React.memo tells React: "Skip this component if its props haven't changed." It is the memoization escape hatch when restructuring alone isn't enough. Just don't overuse it. Wrapping every component in React.memo adds memory overhead and makes your code harder to reason about.

How to Diagnose This in Your Own App

Before you start restructuring your component tree, measure first. Here are the tools that will show you exactly where your renders are wasted:

React DevTools Profiler (built-in)

Open React DevTools → Profiler tab → hit Record → interact with your app → stop. The flamegraph highlights every component that rendered and how long it took.

"Why Did You Render" (npm package)

Install @welldone-software/why-did-you-render. It logs to the console every time a component re-renders unnecessarily, including the exact prop or state change that caused it.

Highlight Updates (React DevTools setting)

In React DevTools → Settings → toggle "Highlight updates when components render." You will see colored flashes around every component that re-renders. If your whole screen is flashing on a single keystroke, you have a colocation problem.

The Checklist

Before you reach for useMemo, useCallback, or a state management library, run through this:

1. 
   Open the React Profiler. Record a few interactions and look at the flamegraph.


2. 
   Find the widest blast radius. Which state change is triggering the most components?


3. 
   Ask: who actually needs this state? If only 2 out of 10 siblings use it, wrap those 2 in a dedicated parent component.


4. 
   Measure again. Compare the before and after flamegraphs.


5. 
   Still slow? Now look at useDeferredValue, React.memo, or a state library.

The order matters. Restructuring is free. Memoization has a cost (memory and complexity). Libraries have a bigger cost (bundle size, learning curve, maintenance). Start cheap.

The Python Lesson That Transfers

Python taught me: keep your variables in the tightest scope possible. Don't use global when local will do. Don't put a variable at the module level if it only matters inside one function.

React works the same way. Every useState you place inside a component defines a blast radius for re-renders. The higher up you place it, the bigger the blast. The lower you push it, the smaller the damage.

State Colocation isn't a hack or a workaround. It is how React is designed to work. Most of us just forget to use it because it is easier to throw state at the top and move on.

Let's Discuss

What's the most expensive unnecessary re-render you have ever tracked down with the React Profiler? Maybe you had a context provider re-rendering your entire app, or a useEffect loop you didn't catch for weeks.

Drop your war story below. The uglier, the better.