メニュー
Use when implementing or testing row/item virtualization (react-window, TanStack Virtual) for large lists (1000-10k+ rows) in a React app whose test suite runs under jsdom rather than a real browser.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | react-virtualization-with-jsdom-measurement |
| description | Use when implementing or testing row/item virtualization (react-window, TanStack Virtual) for large lists (1000-10k+ rows) in a React app whose test suite runs under jsdom rather than a real browser. |
| status | active |
| version | "2026-07-05T00:00:00.000Z" |
Implementing windowed/virtualized rendering for large lists or grids (react-window, TanStack Virtual, or a hand-rolled equivalent) where the test suite runs in jsdom. jsdom does not perform real layout, so virtualization code that depends on measured element sizes needs a deliberate testing strategy — this is that strategy.
Seed non-zero layout in test setup. jsdom's getBoundingClientRect() returns
all-zero rects by default. Stub it in vitest.setup.ts (or equivalent) to return
a fixed non-zero height (e.g. height = 640) for all elements. This unblocks
measureElement-based (dynamic) sizing so tests don't have to fall back to a
fixed estimateSize just because jsdom can't measure.
Use a fixed-height row renderer with absolute positioning for the actual
implementation: mount only the visible viewport (e.g. ~25 rows for a 10k+ row
list) while keeping the full dataset in memory, and position each row with
inline top: pos * rowHeight.
position: absolute, not relative —
with relative, the inline top offset compounds with normal document flow
instead of being the sole positioner, producing visibly wrong (stacking or
overlapping) rows.Test the DOM shape, not pixels. In jsdom, assert things jsdom can actually
represent correctly: rendered row count matches the viewport window (not the
full dataset), the scroll-sizer div's height equals total_rows * rowHeight,
and text content assertions match what's actually in the DOM.
Scope assertions to a specific container (e.g. the grid vs. the card-list
variant) when multiple layout variants render in the same test DOM — otherwise
getByText/getByRole queries fail with "multiple elements found" even though
the component itself is correct.
Verify in both environments. jsdom tests prove virtualization behavior and content (right rows exist, right count, right total height) — they do not prove pixel-perfect visual layout. Confirm smooth scrolling and correct visual virtualization separately in a real browser.
display:none elements measure 0 height in jsdom (unlike real browsers) — a
virtualized tree mounted inside a hidden container (e.g. an inactive tab) won't
get real measurements and can silently defeat windowing logic in tests without
an obvious failure.getBoundingClientRect stub returns the same height for all elements,
expanded/dynamic-height content still lands fully in the DOM in jsdom even though
visually it wouldn't grow the same way in a browser — text-content assertions
remain valid, but don't infer real visual row-growth from jsdom test behavior.position: relative on the row wrapper is a common bug that only shows up
visually (rows overlap/misplace) — it will not fail any content-based jsdom test,
so it must be checked by eye in a real browser, not assumed safe because tests pass.measureElement sizing requires the getBoundingClientRect shim to exist
in test setup ahead of time — without it, tests either fail or force falling back
to a fixed estimateSize, which doesn't exercise the same code path as production.React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Use when implementing multiple related enhancements, or a large feature that must be split across risk boundaries, and you need to decide branch/PR structure. Covers accumulating related work on one shared branch with atomic commits per enhancement, splitting risky multi-PR features along risk seams, and safely handling a branch that has both committed and dirty (uncommitted) work when shipping.
Use when a rebase or merge reports conflicts on a file where both branches only appended or inserted new content (append-only logs, registries, holding-pen documents) rather than editing the same lines. Recognizes the conflict as a false signal and resolves it as a union-keep-both operation instead of a real semantic merge.
Use when reskinning an app with a real brand's visual identity — extract the actual palette from a live site's raw CSS (not markdown), recreate logo/icon assets programmatically with documented extraction rationale, and codify everything as versioned, named design tokens rather than one-off hardcoded values.
Use when building a skill, doc, or knowledge base for an existing internal service or codebase, or when asked to audit past sessions for recurring failures and gaps — mine prior Claude conversation transcripts instead of reverse-engineering from logs or current code alone.