Performance patterns

Fix the structure before you reach for memo

In Profiling React apps, a profile pointed at 15 picks that rendered on every key, and memo skipped them. memo works, but it's often not the best fix. Most slow renders come from where state lives and what a component renders, and a small change to the structure stops the work from starting at all. When React re-renders fixed a gift note that way; this lesson goes through each structural fix with a before and an after, and adds three more: long lists, code that loads later, and slow work inside a component. Here is a tea shop with a newsletter box under its grid of teas. The result is live: type your email in the box.

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4export default function ShopPage() {5  const [email, setEmail] = useState("");6  return (7    <>8      <ProductGrid />9      <footer>10        <label>11          Tea news: <input value={email} onChange={(e) => setEmail(e.target.value)} placeholder="you@example.com" />12        </label>13        <p>{email.includes("@") ? "Looks good." : "Type your email."}</p>14      </footer>15    </>16  );17}

Line 5 keeps the email in ShopPage. Line 8 draws ProductGrid, from the ProductGrid.jsx tab: 12 teas, each card slow on purpose (lines 7 to 10 of that tab wait 3 ms). Lines 9 to 14 are the newsletter footer, and line 13 checks the email as you type. The grid's heading has a render counter from the RenderCount.jsx tab, which counts the renders React put on the page.

Type asha: the counter climbs to renders: 5, one for the first render and one per key, and the letters lag a little. The grid doesn't use the email at all. It renders because it's inside the component whose state changed. Here is the rule that every pattern in this lesson works with:

• A state change renders the component that holds the state and everything it returns, all the way down.
• Components above it and beside it don't render.
• React skips a component only when it can tell nothing changed, like an element that is the same object as last time.

Move state down to the part that uses it

Only the newsletter footer uses email. So give the footer a component of its own, and let that component hold the state. Type asha again:

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4function Newsletter() {5  const [email, setEmail] = useState("");6  return (7    <footer>8      <label>9        Tea news: <input value={email} onChange={(e) => setEmail(e.target.value)} placeholder="you@example.com" />10      </label>11      <p>{email.includes("@") ? "Looks good." : "Type your email."}</p>12    </footer>13  );14}15 16export default function ShopPage() {17  return (18    <>19      <ProductGrid />20      <Newsletter />21    </>22  );23}

Lines 4 to 14 are Newsletter. Line 5 moved here from ShopPage, with the footer it controls. Now ShopPage (lines 16 to 23) has no state at all: it draws the grid on line 19 and the newsletter on line 20. Each key renders Newsletter only, so the grid's counter stays at renders: 1, and the letters keep up.

This is the opposite of lifting state up. You lift state when two components need it; you keep it down when only one does. react.dev gives the same advice: don't lift state higher than it needs to go. Text you're typing, whether a menu is open, which card the mouse is over: these belong in the component that shows them, not at the top of the page or in a global store.

The React Compiler would skip the grid here too: it remembers the <ProductGrid /> element when nothing it depends on changed. Moving state down is still worth doing. It keeps work from starting, it works without a compiler, and the code reads better: the state sits next to the only thing that uses it.

Pass slow parts in as children

Sometimes the state can't move down, because the component that holds it wraps the slow part. Here a TextSizer lets the reader make the tea list bigger or smaller. Its font size has to sit on a <div> around the grid. Click Larger twice:

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4function TextSizer() {5  const [size, setSize] = useState(16);6  return (7    <div style={{ fontSize: size }}>8      <button onClick={() => setSize(size - 2)}>Smaller</button>9      <button onClick={() => setSize(size + 2)}>Larger</button>10      <ProductGrid />11    </div>12  );13}14 15export default function ShopPage() {16  return <TextSizer />;17}

Line 5 keeps the size, and line 7 puts it on the <div>. Lines 8 and 9 change it. Line 10 draws ProductGrid inside. Each click renders TextSizer, and with it the grid: the counter says renders: 3, though the grid's output never changed. Only the CSS font size did.

Now let TextSizer take whatever it wraps as children, and let ShopPage write the grid:

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4function TextSizer({ children }) {5  const [size, setSize] = useState(16);6  return (7    <div style={{ fontSize: size }}>8      <button onClick={() => setSize(size - 2)}>Smaller</button>9      <button onClick={() => setSize(size + 2)}>Larger</button>10      {children}11    </div>12  );13}14 15export default function ShopPage() {16  return (17    <TextSizer>18      <ProductGrid />19    </TextSizer>20  );21}

Line 4 takes children, and line 10 places them. Lines 17 to 19 in ShopPage write <ProductGrid /> between the TextSizer tags. Click Larger twice: the text grows, and the counter stays at renders: 1.

Here's why. <ProductGrid /> is JSX, and JSX makes a plain object, an element, when the component that writes it renders. In the first version, TextSizer wrote it, so every click made a new element, and React rendered the grid. In the second, ShopPage wrote it, and ShopPage doesn't render when TextSizer's state changes. So children is the very same object as last time, and React skips everything inside it. The Context lesson used the same move to avoid passing props through layers.

Look for components that only wrap others: layouts, panels, frames, accordions, a component that tracks scrolling or the window's size. If they hold state and draw their contents themselves, let the parent pass the contents in instead.

Render only the rows on screen

Some pages are slow because they render a lot, not because they render too often. This order history has 5,000 orders, from the orders.js tab. Watch how long the result takes to appear, then type chai in the box:

1import { useState } from "react";2import { orders } from "./orders.js";3 4export default function OrderHistory() {5  const [query, setQuery] = useState("");6  const matches = orders.filter((order) => order.name.toLowerCase().includes(query.toLowerCase()));7  return (8    <>9      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Filter orders" />10      <p>Rows in the page: {matches.length} of {matches.length}</p>11      <ul className="orders">12        {matches.map((order) => (13          <li key={order.id}>#{order.id} {order.name}</li>14        ))}15      </ul>16    </>17  );18}

Line 6 filters the orders, and lines 12 to 14 make a <li> for every match. The list scrolls inside a box 240 pixels tall (the styles.css tab), so only about 8 rows are ever on screen, yet line 10 says Rows in the page: 5000 of 5000. React creates all 5,000 elements, the browser lays them all out, and each key renders and compares every one again.

Virtualizing (also called windowing) means rendering only the rows that are on screen, plus a few around them, and nothing else. Here is a small virtualizer, in the VirtualList.jsx tab, and the same order history using it:

1import { useState } from "react";2import { orders } from "./orders.js";3import VirtualList from "./VirtualList.jsx";4 5export default function OrderHistory() {6  const [query, setQuery] = useState("");7  const matches = orders.filter((order) => order.name.toLowerCase().includes(query.toLowerCase()));8  return (9    <>10      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Filter orders" />11      <VirtualList12        items={matches}13        rowHeight={30}14        height={240}15        renderRow={(order) => `#${order.id} ${order.name}`}16      />17    </>18  );19}

Lines 11 to 16 hand VirtualList the matches, the height of one row, the height of the box, and a function that draws one row. The result says Rows in the page: 10 of 5000. Scroll the list: the count stays around 12, and the row numbers change. Here is how the VirtualList.jsx tab does it:

1. Line 4 keeps how far the box is scrolled, scrollTop, in state. Line 21 updates it on every scroll.
2. Line 5 works out the first row on screen: 3,000 pixels down with 30-pixel rows is row 100 (counting from 0).
3. Lines 6 and 7 add 2 extra rows above and below, so a short scroll already has rows to show, and stay inside the list.
4. Lines 10 to 16 make only those rows. Line 12 places each one exactly where it would be in the full list, with position: absolute and top.
5. Line 22 makes the <ul> as tall as all the rows together, 150,000 pixels, so the scroll bar has the right size and position.

The playground runs the same windowing code on this page. Scroll the list or drag the slider, and switch how many extra rows it adds. The chips show which rows are on screen, which are in the page but off screen, and which aren't in the page at all.

With No extra rows, scroll slowly and you'll see an empty strip at the bottom of the box whenever a row is only partly on screen. That's what the extra rows are for. A few are enough; many more only add work back.

This virtualizer is small on purpose. It needs every row to be the same height, it only scrolls up and down, and it does nothing for keyboard users or screen readers. For a real app, use a library (versions checked in October 2026). react-window 2 renders lists and grids with List and Grid; TanStack Virtual 3 gives you a Hook, useVirtualizer, that works out which rows to draw and leaves the markup to you, and it can measure rows of different heights. Here is the order list with react-window. It isn't live, because the results on this page can only import React:

import { List } from "react-window";

function OrderRow({ index, style, ariaAttributes, orders }) {
  return (
    <div style={style} {...ariaAttributes}>
      #{orders[index].id} {orders[index].name}
    </div>
  );
}

export default function OrderHistory({ orders }) {
  return (
    <List
      rowComponent={OrderRow}
      rowCount={orders.length}
      rowHeight={30}
      rowProps={{ orders }}
      style={{ height: 240 }}
    />
  );
}

Lines 13 to 19 render a List: rowComponent is the component for one row, rowCount how many rows there are, rowHeight their height in pixels, and rowProps extra props for every row. Lines 3 to 9 are that row component. React-window passes it index, a style that places it, and ariaAttributes that tell screen readers the row's position in the whole list; line 5 spreads both onto the row.

One thing to know before you virtualize: rows that aren't in the page can't be found with the browser's find-in-page, and assistive tools only see the rows that are there. For a list of a few hundred simple rows, try the CSS property content-visibility: auto first: every row stays in the page, but the browser skips laying out and painting the ones that are off screen. React still renders all of them, though.

Load rarely used code later with lazy

Some slowness happens before React renders anything: the browser has to download and run your JavaScript first. Every import at the top of a file is part of that first download, even code few readers ever use. In this product page, open the console under the result before you click anything:

1import { useState } from "react";2import ReviewsChart from "./ReviewsChart.jsx";3 4export default function ProductPage() {5  const [showChart, setShowChart] = useState(false);6  return (7    <>8      <h3>Green tea</h3>9      <button onClick={() => setShowChart(true)}>Show the ratings chart</button>10      {showChart && <ReviewsChart />}11    </>12  );13}

Line 2 imports ReviewsChart, and line 10 shows it after a click. The console already says ReviewsChart.jsx runs (line 2 of the ReviewsChart.jsx tab): the chart's code was loaded and run with the page, though you haven't asked for it. In a real app, a chart like this brings a charting library with it, and every reader pays for it on the first load.

The Suspense lesson introduced lazy: it loads a component's code the first time the component renders, using dynamic import(). Here it is for the chart. A pretend download makes the file take a second, so you can see the wait:

1import { Suspense, lazy, useState } from "react";2 3const ReviewsChart = lazy(() => download(import("./ReviewsChart.jsx")));4 5// Pretends the file takes a second to download.6function download(file) {7  console.log("Downloading ReviewsChart.jsx");8  return new Promise((resolve) => setTimeout(() => resolve(file), 1000));9}10 11export default function ProductPage() {12  const [showChart, setShowChart] = useState(false);13  return (14    <>15      <h3>Green tea</h3>16      <button onClick={() => setShowChart(true)}>Show the ratings chart</button>17      {showChart && (18        <Suspense fallback={<p>Loading the chart…</p>}>19          <ReviewsChart />20        </Suspense>21      )}22    </>23  );24}

Line 3 declares the lazy component at the top level of the file. Lines 6 to 9 pretend the download takes a second. Lines 18 to 20 wrap the chart in a Suspense boundary, which shows Loading the chart… while it downloads. Press Run again: the console stays empty until you click. Then it says Downloading ReviewsChart.jsx, and a second later the chart appears. A bundler like Vite puts the chart in a file of its own, so the first download is smaller for everyone.

The reader still waits a second after the click. You can start the download earlier, when the reader shows they're about to click: on hover, or when the button gets keyboard focus:

1import { Suspense, lazy, useState } from "react";2 3let chartDownload = null;4function loadChart() {5  chartDownload ??= download(import("./ReviewsChart.jsx"));6  return chartDownload;7}8const ReviewsChart = lazy(loadChart);9 10// Pretends the file takes a second to download.11function download(file) {12  console.log("Downloading ReviewsChart.jsx");13  return new Promise((resolve) => setTimeout(() => resolve(file), 1000));14}15 16export default function ProductPage() {17  const [showChart, setShowChart] = useState(false);18  return (19    <>20      <h3>Green tea</h3>21      <button onPointerEnter={loadChart} onFocus={loadChart} onClick={() => setShowChart(true)}>22        Show the ratings chart23      </button>24      {showChart && (25        <Suspense fallback={<p>Loading the chart…</p>}>26          <ReviewsChart />27        </Suspense>28      )}29    </>30  );31}

Lines 4 to 7 are loadChart. It starts the download once and keeps the promise in chartDownload, so calling it again returns the same one. Line 8 gives lazy that same function. Line 21 calls it when the pointer enters the button and when the button gets focus. Move the mouse over the button, wait a second, and click: the console says Downloading ReviewsChart.jsx only once, when you hovered, and the chart appears after about a third of a second instead of a whole second. That short wait is React's own: it reveals suspended content at most once every 300 ms, so Loading the chart… flashes briefly. (A real import() of the same file also gives the same module every time; chartDownload is only needed here to make the pretend wait happen once.)

What's worth splitting: whole pages (routers and frameworks like Next.js do this for every route), and big parts that few readers open, like an editor, a chart, a map, or a dialog. What isn't: small components and anything on screen when the page loads. Each split is one more request and one more loading state. To see what's big, look at the file sizes your build prints, or at the Network panel in the browser's developer tools, as Loading performance shows.

Keep expensive work out of rendering

Everything in a component's body runs on every render. Usually that's fine. But slow work that doesn't need to run again shouldn't sit there. This search builds an index of 5,000 products, from the products.js tab, so it can look up a word at once. Open the console, then type green:

1import { useState } from "react";2import { products } from "./products.js";3 4function buildSearchIndex(list) {5  console.log("Building the search index");6  const index = new Map();7  for (const product of list) {8    for (const word of product.name.toLowerCase().split(" ")) {9      if (!index.has(word)) index.set(word, []);10      index.get(word).push(product);11    }12  }13  return index;14}15 16export default function ProductSearch() {17  const [index] = useState(buildSearchIndex(products));18  const [word, setWord] = useState("");19  const matches = index.get(word.toLowerCase()) ?? [];20  return (21    <>22      <input value={word} onChange={(e) => setWord(e.target.value)} placeholder="One word, like green" />23      <p>{matches.length} matches</p>24    </>25  );26}

Lines 4 to 14 build the index: a Map from each word to the products that have it. Line 5 logs each time it runs, a small work counter. Line 17 keeps the index in state. The console shows Building the search index twice when the page loads (StrictMode calls the component twice in development), then two more for every key: 12 lines in all after green, for an index that never changes.

The reason is JavaScript, not React. useState(buildSearchIndex(products)) calls buildSearchIndex first, to get the argument, and only then calls useState, which ignores it after the first render. Pass the function instead, and React calls it only on the first render:

1import { useState } from "react";2import { products } from "./products.js";3 4function buildSearchIndex(list) {5  console.log("Building the search index");6  const index = new Map();7  for (const product of list) {8    for (const word of product.name.toLowerCase().split(" ")) {9      if (!index.has(word)) index.set(word, []);10      index.get(word).push(product);11    }12  }13  return index;14}15 16export default function ProductSearch() {17  const [index] = useState(() => buildSearchIndex(products));18  const [word, setWord] = useState("");19  const matches = index.get(word.toLowerCase()) ?? [];20  return (21    <>22      <input value={word} onChange={(e) => setWord(e.target.value)} placeholder="One word, like green" />23      <p>{matches.length} matches</p>24    </>25  );26}

The only change is on line 17: useState(() => buildSearchIndex(products)). React calls a function it gets as the starting value only on the first render; it's called an initializer. The console shows the line twice when the page loads (StrictMode calls initializers twice too, to help you find impure ones) and never again while you type. Here, products never changes, so the index could even move to the top of the file, outside the component: press Edit & run, write const index = buildSearchIndex(products); after the function, and delete line 17. The console shows the line once, when the file loads.

How to read the table: each row is a kind of slow work, and where it should go.

Two rows point at other lessons. useMemo remembers a calculation between renders and runs it again only when its inputs change; memo, useMemo and useCallback covers it, and The React Compiler adds the same remembering for you. And state copied from other state, through an Effect, is the cascading update from the profiling lesson: You might not need an Effect shows how to remove it.

A catalog that uses every pattern

Here the patterns work together in one catalog of 5,000 teas. Type in the search box, scroll the list, and open the ratings:

1import { Suspense, lazy, useState } from "react";2import { products } from "./products.js";3import VirtualList from "./VirtualList.jsx";4 5const ReviewsChart = lazy(() => import("./ReviewsChart.jsx"));6 7function CatalogSearch() {8  const [query, setQuery] = useState("");9  const matches = products.filter((product) => product.name.toLowerCase().includes(query.toLowerCase()));10  return (11    <>12      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search 5,000 teas" />13      <VirtualList items={matches} rowHeight={30} height={180} renderRow={(product) => product.name} />14    </>15  );16}17 18function Reviews() {19  const [open, setOpen] = useState(false);20  return (21    <section>22      <button onClick={() => setOpen(!open)}>{open ? "Hide" : "Show"} the ratings</button>23      {open && (24        <Suspense fallback={<p>Loading the chart…</p>}>25          <ReviewsChart />26        </Suspense>27      )}28    </section>29  );30}31 32export default function Catalog() {33  return (34    <>35      <h3>Tea catalog</h3>36      <CatalogSearch />37      <Reviews />38    </>39  );40}

Each piece of state lives with the part that uses it: the query in CatalogSearch (line 8), whether the ratings are open in Reviews (line 19). Typing never renders the ratings, and opening them never renders the list. Catalog (lines 32 to 40) has no state, so it renders once. Line 13 virtualizes the matches with the same VirtualList.jsx tab, so typing renders about 8 rows, not 5,000. Line 5 loads the chart's code the first time the ratings open; the console says ReviewsChart.jsx runs only then.

How to read the table: each row is one pattern, when it fits, and what it costs.

Common mix-ups

• "A slow page needs memo." No. Often the state just lives too high, or a wrapper draws its contents itself. Fixing the structure stops the work from starting, with nothing to compare on each render.
• "When a parent renders, its children always render too." No. Elements passed in as children were made by the component above. If that component didn't render, they're the same objects, and React skips them.
• "Keeping all state at the top makes an app faster." No. State at the top renders everything below it on every change. Keep state as low as the components that use it allow.
• "A virtualized list has all its rows in the page, just hidden." No. Only the rows near the screen exist. That's where the speed comes from, and why find-in-page can't see the others.
• "Split every component with lazy." No. Each split is another request and another loading state. Split big, rarely used parts and whole pages.
• "useState(build()) only builds once." No. JavaScript calls build() on every render, before useState sees it. Pass () => build() instead.
• "With the React Compiler, none of this matters." No. The compiler skips renders for you, but it doesn't virtualize lists, split code, or decide where your state should live.

Practice exercises

The grid exercises use the same 12 slow teas, in the ProductGrid.jsx tab, and the same render counter. Change the code with Edit & run; the result updates as you type.

import { useState } from "react";
import ProductGrid from "./ProductGrid.jsx";

export default function ShopPage() {
  const [email, setEmail] = useState("");
  return (
    <>
      <ProductGrid />
      <footer>
        <label>
          Tea news: <input value={email} onChange={(e) => setEmail(e.target.value)} placeholder="you@example.com" />
        </label>
        <p>{email.includes("@") ? "Looks good." : "Type your email."}</p>
      </footer>
    </>
  );
}

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4export default function ShopPage() {5  const [email, setEmail] = useState("");6  return (7    <>8      <ProductGrid />9      <footer>10        <label>11          Tea news: <input value={email} onChange={(e) => setEmail(e.target.value)} placeholder="you@example.com" />12        </label>13        <p>{email.includes("@") ? "Looks good." : "Type your email."}</p>14      </footer>15    </>16  );17}

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4export default function ShopPage() {5  const [showHelp, setShowHelp] = useState(false);6  return (7    <>8      <button onClick={() => setShowHelp(!showHelp)}>Help</button>9      {showHelp && <p>Click a tea to see its details.</p>}10      <ProductGrid />11    </>12  );13}

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4function HelpButton() {5  const [showHelp, setShowHelp] = useState(false);6  return (7    <>8      <button onClick={() => setShowHelp(!showHelp)}>Help</button>9      {showHelp && <p>Click a tea to see its details.</p>}10    </>11  );12}13 14export default function ShopPage() {15  return (16    <>17      <HelpButton />18      <ProductGrid />19    </>20  );21}

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4function HighlightFrame() {5  const [on, setOn] = useState(false);6  return (7    <div style={{ outline: on ? "2px solid orange" : "none", padding: 4 }}>8      <button onClick={() => setOn(!on)}>Highlight</button>9      <ProductGrid />10    </div>11  );12}13 14export default function ShopPage() {15  return <HighlightFrame />;16}

1import { useState } from "react";2import ProductGrid from "./ProductGrid.jsx";3 4function HighlightFrame({ children }) {5  const [on, setOn] = useState(false);6  return (7    <div style={{ outline: on ? "2px solid orange" : "none", padding: 4 }}>8      <button onClick={() => setOn(!on)}>Highlight</button>9      {children}10    </div>11  );12}13 14export default function ShopPage() {15  return (16    <HighlightFrame>17      <ProductGrid />18    </HighlightFrame>19  );20}

1import { useState } from "react";2import { orders } from "./orders.js";3 4export default function OrderHistory() {5  const [query, setQuery] = useState("");6  const matches = orders.filter((order) => order.name.toLowerCase().includes(query.toLowerCase()));7  return (8    <>9      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Filter orders" />10      <p>Rows in the page: {matches.length} of {matches.length}</p>11      <ul className="orders">12        {matches.map((order) => (13          <li key={order.id}>#{order.id} {order.name}</li>14        ))}15      </ul>16    </>17  );18}

1import { useState } from "react";2import { orders } from "./orders.js";3import VirtualList from "./VirtualList.jsx";4 5export default function OrderHistory() {6  const [query, setQuery] = useState("");7  const matches = orders.filter((order) => order.name.toLowerCase().includes(query.toLowerCase()));8  return (9    <>10      <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Filter orders" />11      <VirtualList12        items={matches}13        rowHeight={30}14        height={240}15        renderRow={(order) => `#${order.id} ${order.name}`}16      />17    </>18  );19}

1import { useState } from "react";2import GiftWrapEditor from "./GiftWrapEditor.jsx";3 4export default function Checkout() {5  const [wrap, setWrap] = useState(false);6  return (7    <>8      <h3>Checkout</h3>9      <button onClick={() => setWrap(true)}>Add gift wrap</button>10      {wrap && <GiftWrapEditor />}11    </>12  );13}

1import { Suspense, lazy, useState } from "react";2 3let editorDownload = null;4function loadEditor() {5  editorDownload ??= download(import("./GiftWrapEditor.jsx"));6  return editorDownload;7}8const GiftWrapEditor = lazy(loadEditor);9 10// Pretends the file takes a second to download.11function download(file) {12  console.log("Downloading GiftWrapEditor.jsx");13  return new Promise((resolve) => setTimeout(() => resolve(file), 1000));14}15 16export default function Checkout() {17  const [wrap, setWrap] = useState(false);18  return (19    <>20      <h3>Checkout</h3>21      <button onPointerEnter={loadEditor} onFocus={loadEditor} onClick={() => setWrap(true)}>22        Add gift wrap23      </button>24      {wrap && (25        <Suspense fallback={<p>Loading the editor…</p>}>26          <GiftWrapEditor />27        </Suspense>28      )}29    </>30  );31}

1import { useState } from "react";2import { products } from "./products.js";3 4function buildSearchIndex(list) {5  console.log("Building the search index");6  const index = new Map();7  for (const product of list) {8    for (const word of product.name.toLowerCase().split(" ")) {9      if (!index.has(word)) index.set(word, []);10      index.get(word).push(product);11    }12  }13  return index;14}15 16export default function ProductSearch() {17  const [index] = useState(buildSearchIndex(products));18  const [word, setWord] = useState("");19  const matches = index.get(word.toLowerCase()) ?? [];20  return (21    <>22      <input value={word} onChange={(e) => setWord(e.target.value)} placeholder="One word, like green" />23      <p>{matches.length} matches</p>24    </>25  );26}

1import { useState } from "react";2import { products } from "./products.js";3 4function buildSearchIndex(list) {5  console.log("Building the search index");6  const index = new Map();7  for (const product of list) {8    for (const word of product.name.toLowerCase().split(" ")) {9      if (!index.has(word)) index.set(word, []);10      index.get(word).push(product);11    }12  }13  return index;14}15 16export default function ProductSearch() {17  const [index] = useState(() => buildSearchIndex(products));18  const [word, setWord] = useState("");19  const matches = index.get(word.toLowerCase()) ?? [];20  return (21    <>22      <input value={word} onChange={(e) => setWord(e.target.value)} placeholder="One word, like green" />23      <p>{matches.length} matches</p>24    </>25  );26}

Check your understanding

For each question, ask what changed, which component holds it, and what that component made new.

Key takeaways

• A state change renders the component that holds it and everything it returns. Nothing above or beside it renders.
• Keep state in the component that uses it. Lift it only as far as the components that share it.
• A wrapper with state should take its contents as children: elements made by a parent that didn't render are the same objects, and React skips them.
• For long lists, render only the rows near the screen. Use react-window or TanStack Virtual in real apps, and remember that find-in-page only sees rows in the page.
• Load big, rarely used parts with lazy and import(), and start the download on hover or focus.
• Keep slow work out of rendering: at the top of the file, in a state initializer, in useMemo, or in an event handler.
• Measure first, and prove each fix with a counter or a second profile.

Coming next: Component composition. It builds on children: slots, compound components, and components that hand control back to the code that uses them.