One component with switchable options, virtualization and windowing

[yaotzin1]

Every capability was becoming a component: a tree was TreeGridwright, row actions were BubbleMenu composed by hand, editing was editableColumns plus InlineEditProvider composed by hand. Each worked. None of them worked together without reassembling the component's own arrangement, and the tree was a parallel implementation that could never gain anything added to <Gridwright />.

They are now options on one component, and they compose:

<Gridwright
    columns={columns}
    data={folders}
    tree={{ getRowId, getChildren, controllerRef: setTree }}
    virtual
    rowActions={actions}
    onCellEdit={commit}
/>

Each piece is still exported for a layout composed by hand, and TreeGridwright survives as an alias with no second implementation behind it.

Scale, which is two problems

• virtual renders only the rows on screen, carrying the rest in two spacer <tr> rows so the element stays a real <table role="grid"> with real column alignment. aria-rowcount and aria-rowindex carry the true numbers.
• createWindowedDataSource holds blockSize * maxBlocks rows however large the result set is.

Measured in the browser at ten million rows: 23 rendered rows, 2 blocks cached, 400 rows resident, 2 range requests.

Two bugs the test suite did not find

Driving the playground in Chrome found both.

• The last nine and a half million rows were unreachable. A browser will not render an element taller than about 2^24 pixels, so the scrollbar stopped at row ~419,000 while aria-rowcount claimed ten million, silently. Above that height scroll position is now a ratio over the result set, with the cost written down rather than hidden.
• Two overlapping window fetches could leave the grid empty and ready. A block being loaded for a request that was then aborted was joined by the next request, resolved carrying nothing, and the survivor built its window from an empty cache. A load is now only joined while its own request is alive, and blocks carry the generation of the cache they were fetched for.

Both have regression tests.

Documentation

Updated everywhere it was wrong: README, docs/tree.md, docs/data-sources.md, docs/extensibility.md, the docs index, the playground README, the two agent rules that claimed this package has no virtualization, and DEPENDENCY_MAP.md. New: docs/virtualization.md and specs/unified-options/ with all eight artifacts.

Semver

Minor. Six optional props, one optional column field, two optional GridTable props, and new exports. No signature, removal or default changed, so a 0.3.0 grid renders identically. Version 0.4.0.

Verification

npm run verify: 297 unit tests, 12 smoke tests, lint and typecheck green. Plus a manual pass over the playground in Chrome: every switch and combination, ten million rows scrolled to row 10,000,000, and an edit committed over the windowed source with the block cache dropped and refetched.

🤖 Generated with Claude Code

https://claude.ai/code/session_011ndm72nQiMLvEqekHNJuAV

[yaotzin1]

Two follow-up commits, both driven by using the pages rather than by the suite.

Four bugs the playground found, each with a regression test confirmed to fail without its fix:

• Virtualization over an ordinary paginating source never placed its rows. Only the windowed source publishes where its rows start, and a missing offset was read as zero, so the fetched page was drawn over rows one to a hundred while the rows on screen stayed skeletons for ever.
• Switching editing off took the grid down. The engine resolves columns in an effect, so for one render the rows still held editable cells while the prop was already gone. The tree made it permanent: its column wrapping was keyed on ids alone and so never re-wrapped.
• A column's icon sat beside its editable trigger rather than inside it, so clicking the icon did nothing.
• The row action menu opened a row too low: positioned inside a zero-height anchor, measured against the grid root.

All three pages now carry the new capabilities. The vanilla page gets the windowed source over ten million rows with no framework involved anywhere on it, talking to a new /api/people/range endpoint so the memory claim crosses a real network boundary. The React page gets row actions, inline editing and windowing as switches over its paginating REST source.

rowDataOf(row) was added because a tree's rows are placements: without it, a menu written for a flat grid breaks the moment tree is switched on, which makes the switch a lie.

npm run verify: 304 unit tests, 12 smoke tests, lint and typecheck green.

🤖 Generated with Claude Code

https://claude.ai/code/session_011ndm72nQiMLvEqekHNJuAV