How to Test React-Window List with Playwright: Virtualized Scrolling, Variable Heights, and Off-DOM Items

3. Scenario: Verifying Initial Render and Visible Window

Goal: Confirm that the list renders the correct number of visible items on initial load, that the first item is visible, and that items beyond the visible window plus overscan are not present in the DOM.

Preconditions: A react-window FixedSizeList with 1,000 items, each 35px tall, in a container 400px high. The default overscan count is 1.

The visible window fits approximately 11 items (400 / 35, rounded up), and with an overscan of 1, react-window renders about 13 items total. Your test should verify that the first item is visible, that approximately 13 items exist in the DOM, and that item 50 is not present.

What to assert beyond the UI:Verify the inner container's total height matches the expected value (item count multiplied by item height). This confirms react-window has correctly calculated the scrollable area. If this value is wrong, scroll-to-index calculations will land on the wrong item.

4. Scenario: Scroll-to-Index Navigation

Goal: Use react-window's scrollToItem API (triggered by a UI button or exposed ref) to jump to a specific row and verify it appears in the visible area.

Preconditions:The list exposes a "Jump to row" input that accepts an index number and calls listRef.current.scrollToItem(index) on submit.

The key challenge here is timing. After scrollToItemis called, react-window updates the container's scrollTop synchronously, but the visible items re-render asynchronously. Your test must wait for the target item to appear in the DOM before asserting on its content. A naive approach of querying immediately after the scroll call will fail because the new items have not mounted yet.

test('scrollToItem navigates to row', async ({ page }) => {
  await page.goto('/list-demo');
  const jumpInput = page.locator('[data-testid="jump-to-input"]');
  const jumpButton = page.locator('[data-testid="jump-to-button"]');
  await jumpInput.fill('500');
  await jumpButton.click();
  const targetItem = page.locator('[data-testid="list-item-500"]');
  await expect(targetItem).toBeVisible({ timeout: 5000 });
  await expect(targetItem).toHaveText(/Item 500/);
  const neighbor = page.locator('[data-testid="list-item-501"]');
  await expect(neighbor).toBeAttached();
});

5. Scenario: Variable-Height Rows

Goal: Test a VariableSizeList where each row has a different height based on its content length. Verify that scroll-to-index still lands on the correct item and that the total scroll height reflects the sum of all individual row heights.

Why this is hard: With FixedSizeList, the scroll offset for any index is simply index * itemHeight. With VariableSizeList, react-window must sum the heights of all preceding items to calculate the offset. If your itemSizefunction returns an estimated height and the actual rendered height differs, items will visually jump as react-window corrects the positions. This "content shift" breaks tests that check bounding boxes immediately after scrolling.

React-virtuoso handles this differently by measuring items after render and adjusting positions dynamically. This means react-virtuoso tests must account for a measurement phase where items may temporarily have incorrect positions. The test below handles both cases.

What to assert beyond the UI: When testing variable-height lists, always verify the total scroll height of the inner container. If the itemSize function returns incorrect values, the scroll height will be wrong and every scroll-to-index operation will land on the wrong item. Catching the scroll height mismatch early prevents an entire class of downstream assertion failures.

6. Scenario: Keyboard Navigation and Focus Management

Goal: Verify that arrow key navigation moves focus through list items, that the list scrolls to keep the focused item visible, and that focus is not lost when items are recycled (unmounted and remounted by the virtualizer).

Why this is tricky: When the user presses the down arrow and the focused item scrolls out of the visible window, react-window unmounts that DOM element. If your application stores focus on the DOM node itself (via tabIndex and ref.focus()), the focus disappears when the node is recycled. Accessible virtualized lists must manage focus at the container level using aria-activedescendant instead of moving DOM focus to each item. Your test must verify both the visual scroll position and the aria state.

7. Scenario: Dynamic Data Loading (Infinite Scroll)

Goal: Test that scrolling to the bottom of the list triggers a data fetch, that a loading indicator appears during the fetch, that new items are appended without disturbing the scroll position, and that the list stops fetching when all pages are loaded.

Preconditions: The list loads 50 items initially and fetches 50 more when the user scrolls within 200px of the bottom. The API returns paginated data with a hasMore flag.

Infinite scroll with virtualization is one of the hardest patterns to test because it combines two asynchronous behaviors: the scroll-triggered re-render from react-window and the network request for new data. Your test must coordinate both. The approach below uses Playwright route interception to control the API response timing, ensuring deterministic test behavior.

test('infinite scroll loads next page', async ({ page }) => {
  let requestCount = 0;
  await page.route('**/api/list*', async (route) => {
    requestCount++;
    const url = new URL(route.request().url());
    const pageNum = parseInt(url.searchParams.get('page') || '0');
    const items = generateItems(pageNum, 50);
    await route.fulfill({
      status: 200, contentType: 'application/json',
      body: JSON.stringify({ items, hasMore: pageNum < 3 }),
    });
  });
  await page.goto('/list-demo?mode=infinite');
  const container = page.locator('[data-testid="virtual-list"]');
  await container.evaluate((el) => {
    el.scrollTop = el.scrollHeight - el.clientHeight - 100;
  });
  await expect(page.locator('[data-testid="loading-indicator"]')).toBeVisible();
  await expect(page.locator('[data-testid="loading-indicator"]')).not.toBeVisible();
  expect(requestCount).toBe(2);
});

8. Scenario: Overscan Count and Scroll Performance

Goal: Verify that the overscan count configuration affects how many extra items are rendered beyond the visible window, and measure scroll performance to ensure the overscan setting provides smooth scrolling without excessive DOM node creation.

The overscanCount prop in react-window controls how many items are rendered above and below the visible area. A higher overscan count means smoother scrolling (fewer blank flashes) but more DOM nodes. A lower count means better initial render performance but a higher risk of the user seeing blank space during fast scrolling. Testing this involves counting rendered nodes and measuring frame timing during scroll operations.