Data heavy optimization

Data-Heavy Lists and Computation

This skill identifies array calls inside components that render JSX, .map() lists directly in JSX, and explicit pagination or virtualization signals. Findings are structural candidates: they do not know the item count, commit cost, memory use, or target device, and they do not claim a performance gain.

Memory and patterns

Read the local MEMORY.md and follow ../.shared/SKILL-MEMORY-PROTOCOL.md; use node "<skills-root>/.shared/src/memory-cli.js" append ... for actionable results. The utility validates, renumbers, and retains up to 12 entries.

Before making decisions influenced by existing code, follow ../.shared/PATTERN-LEARNING-PROTOCOL.md and query the repository catalog with node "<skills-root>/.shared/src/pattern-learning/pattern-cli.js" query ...; after confirming a new or refined pattern in the code, consolidate it with node "<skills-root>/.shared/src/pattern-learning/pattern-cli.js" upsert ....

Compatibility and usage

Compatible with React 18/19, Vite 7/8, and Node 22.13+. The scanner uses the TypeScript AST for .js, .jsx, .ts, and .tsx, ignores tests and stories, and does not run the application:

node "<skill-dir>/scripts/scan-heavy-data.js" ./src --format json --dry-run
node "<skill-dir>/scripts/scan-heavy-data.js" ./src --output ./validation-results/data --format markdown

--output is a directory; generated files are named data-heavy-report.md or .json. All other output behavior follows the shared CLI contract in ../.shared/README.md.

When not to use

• The list is small or the computation cheap; for prop-identity issues prefer the memoization-optimization skill.
• The problem is initial transfer or build output, not render cost; use the bundle-optimization skill.

Decision process

1. Measure item count, DOM nodes, memory, median and p95 duration, and commits with the same dataset and flow.
2. If computation outside useMemo is expensive and repeated, correct dependencies or extract a pure function; use useMemo only when cost has been observed.
3. For genuinely large lists, compare pagination or infinite scrolling with virtualization. Virtualization requires correct sizing or measurement, accessibility, keyboard support, overscan, and scroll restoration.
4. If you use a library, declare the dependency and follow the installed version's API (@tanstack/react-virtual, react-window, and so on). The after/HeavyList.jsx example demonstrates simple native windowing and does not replace an accessible library.
5. Repeat the scenario with the same load and record gains, regressions, noise, or no impact. Removing a scanner finding is a structural change, not a metric.

Supporting techniques

• For long lists that remain fully rendered, content-visibility: auto with contain-intrinsic-size lets the browser skip layout and paint of off-screen items; it complements, not replaces, virtualization and accessibility work.
• Build a Map index for repeated lookups by the same key instead of repeated .find() calls (1000 × 1000 lookups: about 1M operations down to 2K).
• Treat props and state as read-only: use .toSorted(), .toReversed(), .toSpliced(), or .with() instead of mutating array methods (spread fallback for older environments).

Limitations

The scanner does not infer an array's actual size, verify whether a hook is appropriate, analyze operations in imported helpers, guarantee that a component is accessible, or detect every windowing pattern. Names such as visibleStart and data-virtualized are only signals that a strategy already exists.

Files

• scripts/scan-heavy-data.js: deterministic AST/JSX scanner and CLI.
• checklists/data-heavy-checklist.md: diagnostic and measurement checklist.
• examples/before: computation and a list without windowing.
• examples/after: useMemo with complete dependencies and native windowing that preserves filtering and sorting.
• examples/pagination: explicit pagination.
• examples/infinite-scroll: infinite scrolling with IntersectionObserver and incremental rendering.