Profile and fix a filterable React list where unrelated state repeatedly sorts a large unchanged collection and rerenders every row.

• Capture a baseline profile before changing the code.
• Never mutate the incoming items array while sorting.
• Include every semantic dependency in memoization.
• Use stable item ids as keys; array indexes are not acceptable.
• Memoize a callback only when a memoized child benefits from stable identity.
• Preserve correct updates when item objects or the query change.
• Explain when pagination or virtualization is more valuable than memoizing all rows.

1. Profile an unrelated state update and a search update; record which component commits and where time is spent.
2. Keep filtering and sorting as derived data rather than mirrored state. Wrap the expensive calculation in useMemo with items and query as complete dependencies.
3. Copy before sorting so props are not mutated.
4. Extract and memoize ProductRow; pass the minimum stable props it needs.
5. Stabilize handleSelect with useCallback because row memoization otherwise sees a new function each render.
6. Reprofile the same interactions and remove any memoization that adds complexity without reducing measured work.
7. If mounting thousands of DOM rows remains dominant, propose windowing or pagination as the next boundary.

import { memo, useCallback, useMemo, useState } from "react";

type Product = { id: string; title: string; price: number };

const ProductRow = memo(function ProductRow({
  product,
  selected,
  onSelect,
}: {
  product: Product;
  selected: boolean;
  onSelect: (id: string) => void;
}) {
  return (
    <li>
      <button
        type="button"
        aria-pressed={selected}
        onClick={() => onSelect(product.id)}
      >
        {product.title} - {product.price}
      </button>
    </li>
  );
});

export function ProductList({
  items,
  onSelect,
}: {
  items: Product[];
  onSelect: (id: string) => void;
}) {
  const [query, setQuery] = useState("");
  const [selectedId, setSelectedId] = useState<string | null>(null);
  const [detailsOpen, setDetailsOpen] = useState(false);

  const visibleItems = useMemo(() => {
    const term = query.trim().toLocaleLowerCase();
    return items
      .filter((item) => item.title.toLocaleLowerCase().includes(term))
      .slice()
      .sort((left, right) => left.title.localeCompare(right.title));
  }, [items, query]);

  const handleSelect = useCallback((id: string) => {
    setSelectedId(id);
    onSelect(id);
  }, [onSelect]);

  return (
    <>
      <label>
        Search products
        <input value={query} onChange={(event) => setQuery(event.target.value)} />
      </label>
      <button type="button" onClick={() => setDetailsOpen((open) => !open)}>
        {detailsOpen ? "Hide details" : "Show details"}
      </button>
      <ul>
        {visibleItems.map((product) => (
          <ProductRow
            key={product.id}
            product={product}
            selected={product.id === selectedId}
            onSelect={handleSelect}
          />
        ))}
      </ul>
    </>
  );
}

This depends on callers treating item objects as immutable. If the parent recreates every item object on each render, row memoization cannot help until that upstream identity churn is fixed.

Filtering is O(n) and sorting is O(m log m) for m matched items. useMemo avoids that work only while its dependencies retain identity; it also retains the derived array and performs dependency comparisons. memo adds prop comparisons and helps only when skipped row renders cost more than those comparisons. Rendering 5,000 DOM nodes can still dominate, so virtualization, server filtering, or pagination may be the correct production improvement after measurement.

• The parent mutates items in place, so reference-based dependencies do not observe a change.
• The parent recreates every product object or onSelect callback each render.
• Locale-aware sorting is expensive or produces unexpected ordering.
• Duplicate or unstable ids break row identity.
• Selection changes correctly rerender the old and new selected rows.
• Empty and whitespace-only queries restore the full list.
• The list is too large for DOM rendering even after calculation work is reduced.

• Use profiler evidence or instrument the sorter to prove unrelated state does not recompute it.
• Count selected row renders and confirm unrelated rows remain unchanged.
• Replace the items array and verify filtering and sorting recompute.
• Change the query and verify ordering and matching remain correct.
• Freeze the input array in a test so accidental in-place sorting fails.
• Verify selection calls the public callback with the stable id.
• Compare the same production build and interaction before and after; development Strict Mode render counts are not a performance benchmark.

• sort() mutates the prop array and creates correctness bugs.
• A dependency is missing, so the visible list becomes stale.
• memo is added while every prop still receives a new object or function.
• Array indexes are used as keys and row state moves when ordering changes.
• Memoization is applied everywhere without a baseline profile.
• The optimization reduces calculations but ignores thousands of mounted DOM nodes.
• Render counts from development Strict Mode are treated as production timings.