Large Datasets
How to hold a hundred thousand rows, or a million: infinite scroll over a server that pages, or numbered pages when deep links matter more. The grid only ever asks for the window it is showing.
Infinite scroll over 100,000 rows
Rows are generated on demand from the row index — the array is never built. The counter shows every window the grid has asked for.
Windows fetched so far: 1 · 100,000 rows in the dataset
Numbered pages instead
The same data source and the same hundred thousand rows, with scrollMode: 'paging'. A page change replaces the rows rather than appending them, so the grid never holds more than one page.
Windows fetched so far: 1 · one request per page turn
Refetch or recompute
Two grids from one factory, differing only in sortMode and filterApplyMode. Sort a column or pick a Site on each and watch the counters: the server grid goes back for new rows, the client grid works with what it already has.
sortMode & filterApplyMode: 'server'
Requests: 1
sortMode & filterApplyMode: 'client'
Requests: 1
A hundred thousand rows, one window at a time
The grid asks the data source for the rows it needs and nothing else. Scrolling to the far end of a hundred thousand rows costs the same per step as scrolling the first screen — what grows is the number of requests you have made, not the size of any one of them.
The demo above generates its rows from the row index rather than loading an array, so
nothing about the page's weight depends on the row count. The code sample beside it is
the shape you would actually ship: a data source that hands
offset, limit, sorts and filters to
a server.
Continuous scroll or numbered pages
Both modes ask the same data source the same question — give me rows
offset to offset + limit — so switching between them
changes one config line and nothing on your server.
-
scrollMode: 'infinite'keeps every window it has loaded and appends the next one as you reach it. Best when reading is continuous and the row you want is somewhere below. -
scrollMode: 'paging'replaces the rows on every page change and never holds more than one page. Best when a page number is a place people return to — it is the mode that survives being put in a URL.
Which actions reach your server, and which do not
This is the question that decides how a large dataset behaves under a user, and the
answer is one pair of config keys rather than a rule you have to remember.
sortMode and filterApplyMode each take
'server' or 'client', and the two grids above differ in
nothing else.
-
'server'— the sort or filter travels tofetchRows()onFetchParams. Your backend orders or narrows the whole dataset and returns a different window. Correct across all hundred thousand rows; costs a request. -
'client'— the grid works on the rows it has already loaded and sends emptysorts/filters, so the source keeps returning the full dataset. Instant and free; only ever covers what is loaded.
Scrolling always reaches the source, in either mode — that is what fetches the next window. Expanding a row, selecting, reordering a column and resizing never do: none of them changes which rows the grid is showing.
The honest default for a hundred thousand rows is 'server' for both. Reach
for 'client' when the dataset the user is working inside is genuinely
loaded — a filtered subset, a single page — and the round trip is the thing you want to
remove.
What a large dataset costs
| Property | Type | Default | Description |
|---|---|---|---|
| config.scrollMode | 'infinite' | 'paging' | 'infinite' | Continuous scroll that appends windows, or numbered pages that replace them. Both call the same fetchRows(). |
| config.pageSize | number | — | The limit the grid asks for. Larger means fewer, bigger requests — the trade the counters above make visible. |
| config.sortMode | 'server' | 'client' | 'server' | server sends sorts to your data source and refetches. client reorders the loaded rows and sends none. |
| config.filterApplyMode | 'server' | 'client' | 'server' | The same choice for filtering. client needs scrollMode: 'infinite'. |
| FetchParams.offset / limit | number | — | The window being asked for. Everything on this page is a consequence of the grid only ever asking for one. |
| FetchResult.totalCount | number | — | The size of the whole dataset. Drives the scroll length and the pager — the grid never needs the rows to know it. |