DataPage clips its paginator in a bounded-height container when actions are present

[woksin]

Problem

DataPage does not allocate the bounded page height between its action bar and query table. With @cratis/components 2.7.0, a DataPage inside a 560px-high container, with DataPage.MenuItems and a paged snapshot query returning 24 rows, clips the lower table rows and the paginator. The rows can scroll inside the table wrapper, but the paginator remains below the clipped page boundary and is unreachable.

Source evidence

At tag v2.7.0:

• Source/DataPage/DataPage.tsx renders MenuItems and Columns as siblings in an Allotment.Pane whose only layout class is flex-grow.
• Source/DataTables/DataTableForQuery.tsx gives its outer table container height: 100%.
• Source/Common/Page.tsx clips its panel with overflow-hidden.

The table therefore claims the full pane height before the action bar is accounted for. Their combined height exceeds the pane and Page clips the end. The current PrimeReact 11 migration branch in PR #107 retains the same sibling layout, so the defect is not specific to the old paginator implementation.

Reproduction

<div style={{ height: 560 }}>
    <DataPage title="Users" query={PagedUsers} emptyMessage="No users">
        <DataPage.MenuItems>
            <MenuItem label="Invite" command={invite} />
        </DataPage.MenuItems>
        <DataPage.Columns>
            <Column field="name" header="Name" />
        </DataPage.Columns>
    </DataPage>
</div>

Return 24 records with a page size of 20. On page one, the paginator is outside the reachable bounded surface. On page two, where only four rows render, it becomes visible again.

Expected

The action bar consumes intrinsic height, the table region receives the remaining height with min-height: 0, rows scroll within that region, and the paginator remains visible/reachable at every page size.

Acceptance

• The primary Allotment.Pane establishes a min-height: 0 flex-column layout.
• The action area does not shrink.
• The columns/table region receives flex: 1; min-height: 0 and owns row scrolling.
• A bounded-height story or browser spec with more than one page verifies the paginator is visible and clickable while the row region scrolls.
• The same layout works with and without MenuItems and with the optional details pane.

[woksin]

Fixed in 2.7.1 (PR #127, merge 4e4156a).

Two causes, and the second is the one this report's acceptance criteria caught.

The table grew to its content instead of filling the pane, so a full page of rows pushed the paging controls past the bottom of the frame and Page's overflow-hidden clipped them. A short page fit and looked correct, which is why this only appears once there is enough data.

The first fix removed the split view from the path that does not need one — but a page with a details component still mounts one, and the split view positions its panes from a stylesheet the package never imported. So the pane stayed an ordinary block that grew to content, height: 100% resolved to auto, and the paginator was clipped exactly as before; the two panes also stacked instead of siding. Your acceptance line — "the same layout works with and without MenuItems and with the optional details pane" — is what made that gap visible. The component now imports that stylesheet itself, the way every other component here imports the one it needs, so there is nothing for a consumer to add.

The specs could not have caught any of this, and that is fixed too. Every assertion was on an inline style declaration, and jsdom applies no stylesheets — it cannot distinguish an honored height: 100% from an inert one. Reverting the primary fix left all 375 tests passing. The runner now processes that one stylesheet, so the specs read computed values: an unpositioned pane reads as static / auto against an expected absolute / 100%, and the previously-undetectable mutation now fails. The containment claims also assert the paginator exists before claiming where it sits — scrollRegion.contains(paginator) was satisfied by the paginator being absent, since Node.contains(null) is false.

Two limitations, stated rather than glossed. Your report asked for a bounded-height story or browser spec verifying the paginator is visible and clickable. The stories exist; the browser spec does not. This repo has no browser-mode test capability at all, and adding one means a new test stack, a second Vitest project, a playwright install CI step and browser-binary maintenance — assessed and deliberately not built for one assertion. What the computed-style change buys is the ability to tell honored from inert; layout itself — "visible and clickable" — remains uncovered, and only a real browser can cover it.

Second: minHeight: 20rem is applied as an unconditional floor, not the fallback the documentation describes. A DataPage inside a bounded ancestor shorter than 20rem is forced taller and overflows it, with no way to opt out. That is a separate defect from the one you reported and wants a minHeight prop, which is a public-API addition — worth its own issue if it affects you.