Uh oh!
There was an error while loading. Please reload this page.
fix(list): server-side pagination through ListView → ObjectGrid (#2212) - #1916
Merged
Conversation
The merged ObjectGrid server-pagination (#1913) never engaged for a real list view. ListView fetches its own data and passes the window DOWN to the child object-grid as a `data` prop, which ObjectGrid treats as inline/static value data → hasInlineData=true → useServerPagination=false. So the inner DataTable client-paginated the single window: footer showed pages = window / pageSize and records past the first window were unreachable — exactly the #2212 symptom, on top of the now-fixed framework `findData` total/hasMore. Fix (single pager, server-driven — no second pager added): - ObjectGrid: honour EXTERNAL manual-pagination props (manualPagination / rowCount / page / onPageChange / onPageSizeChange) supplied by a host even when data arrives inline, forwarding them to the one DataTable pager (gated !isGrouped). Own-fetch server pagination is unchanged. - ListView: own server pagination for the flat grid view — track page + total, send $skip = (page-1)*size, read the real match `total`, and hand the window + manual-pagination props to the child grid so its existing single pager becomes server-backed. Reset to page 1 (by value signature) on object/ filter/sort/search/grouping/page-size change. Suppress the "showing first N" cap warning once a real total is known. Tests: ObjectGrid external-manual passthrough (2) + ListView→grid server pagination contract incl. $skip refetch and page-size reset (4). Live-verified on the EHR production_plan list (3125 rows): one pager reading "第 1 页, 共 32 页", last page reachable showing records #3101–3125, $skip=3100 round-trips with total=3125.
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
Uh oh!
There was an error while loading. Please reload this page.
os-zhuang pushed a commit
that referenced
this pull request
Jun 23, 2026
…drop duplicate ListView <select> (#1919) * fix(grid): rows-per-page selector honors pagination.pageSizeOptions; drop duplicate ListView <select> The DataTable pager hardcoded its rows-per-page choices to 5/10/20/50/100, ignoring view metadata, while ListView separately rendered its own native <select> from pagination.pageSizeOptions. For a grid that produced TWO page-size controls with different option sets. - data-table: add pageSizeOptions prop; the selector renders the configured options (current pageSize merged in, de-duped, sorted) instead of the hardcoded list. - ObjectGrid: forward schema.pagination.pageSizeOptions to the DataTable so the single server-driven pager exposes the configured choices. - ListView: suppress the redundant native <select> for grid view (the DataTable pager owns it); keep it only for pager-less views (gallery/ kanban/calendar). - types/zod: declare DataTableSchema.pageSizeOptions. Follow-up to #1916 (#2212). Verified in browser against a 3125-row plan grid: single selector with 50/100/200/500, switching 500 -> 7 pages, last page loads the 125-row remainder. * fix(grid): align selection checkbox column header with body; pad pager - selection checkbox: header (px-4) and body (px-3 from cellClassName) cells had mismatched left padding, so the header checkbox sat ~4px right of the body checkboxes. Force both selection cells to px-0 + text-center so the checkbox centers in the column identically (verified: both at x=264). - pagination footer: the rows-per-page / page-info row had no horizontal padding and sat flush against the table edge. Add px-3 sm:px-4 py-2 to match the table cells and the grouped pager. * fix(data-table): restore left gutter on selection column The previous px-0 fix aligned the header/body checkboxes but removed the column's left padding entirely, leaving the checkboxes flush against the table's left border. Use px-3 (matching the data cells) on both the header and body selection cells: identical padding keeps the checkboxes aligned while restoring a 12px left gutter. * fix(grid): align column headers with body cell padding Root cause of the header/content misalignment: ObjectGrid's applyDensity gave every body cell px-3 (12px) via rowHeightCellClass but left the header at the primitive <th> default px-4 (16px), so every left-aligned header label sat 4px to the right of its data. Add px-3 to the header className in applyDensity (and the right-pinned branch) so headers share the body's horizontal padding. Also align the row-number (#) header to px-3 in data-table. Verified: all 16 columns now match (0 mismatches).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Follow-up to #1913. That PR made ObjectGrid do true server-side pagination, but it never engaged for an actual list view — the original #2212 symptom persisted in the app.
Root cause:
ListViewfetches its own data and passes the window down to the childobject-gridas adataprop. ObjectGrid treats a passeddataarray as inline/static value data (hasInlineData = true), which forcesuseServerPagination = false. So the innerDataTableclient-paginated the single fetched window:pages = window / pageSize(e.g. "共 10 页" capped at 100 rows)This is exactly #2212, layered on top of the now-fixed framework
findDatatotal/hasMore(objectstack-ai/objectstack#2222).What
Single pager, server-driven — no second pager added (the existing inner DataTable pager is reused):
manualPagination/rowCount/page/onPageChange/onPageSizeChange) supplied by a host even when data arrives inline, forwarding them straight to the one DataTable pager (gated!isGrouped). ObjectGrid's own-fetch server pagination from fix(grid): ObjectGrid 真正的服务端分页 (#2212) #1913 is unchanged.$skip = (page-1)*size, read the real matchtotal, and hand the window + manual-pagination props to the child grid. Reset to page 1 (by value signature, so ListView's own mount-time sort/grouping re-inits don't snap the page) on object/filter/sort/search/grouping/page-size change. Suppress the "showing first N" cap warning once a real total is known.Tests
$skip, real total + manual props handed down, page turn refetches with$skip, page-size change resets to page 1 (4)Live verification (EHR
production_plan, 3125 rows)ceil(3125/100)=32), not "共 10 页".wait表单仍提供已退役的waitEventConfig.timeoutMs/.onTimeout—— 下一次 spec rc 刷新会被对账测试点名 #3101–3125 ("25 条记录"), impossible before the fix.$skip=3100round-trips withtotal=3125; exactly one pagination region in the DOM.Refs #2212. Depends on framework
findDatatotal/hasMore fix (objectstack-ai/objectstack#2222).