# Server-Side Row Model: a walkthrough
One grid and one `getRows`, and the rows stay on the server: a page at a
time first, then infinite scroll, then grouped with subtotals and a
grand total, then a panel the user groups with, an edit that becomes a
transaction, and a selection that is a rule rather than a list. Each
step is a change to the same setup, and every example runs against a
server written on this page, so the request and the answer are in
front of you. The [row model hub](https://svgrid.com/docs/help/server/server-row-model/) is the
contract in full; the deep dives ([grouping](https://svgrid.com/docs/help/server/server-grouping/),
[tree data](https://svgrid.com/docs/help/server/server-tree-data/), [pivot](https://svgrid.com/docs/help/server/server-pivot/),
[transactions](https://svgrid.com/docs/help/server/server-transactions/), [selection](https://svgrid.com/docs/help/server/server-selection/))
go further on each part.
The flat controller is free in `@svgrid/grid`; the row model that
groups, pivots and selects across unloaded rows is `@svgrid/enterprise`,
on the same contract.
## The server
Just under twenty thousand sales rows in an array, and a `getRows` that does what an
endpoint does: filter, sort, slice the block asked for, and when the
request says `groupBy`, run the GROUP BY for the level being expanded.
It also answers the write side, so an edit later on has somewhere to go.
Read it once; every example below talks to it.
```svelte
```
## A page at a time
`createServerDataSource` is the free controller: it turns the grid's
sort, filter and pager into one `getRows` per change, tags each request
so a slow answer cannot overtake a fast one, and hands the grid a row
model. `rowModel={ctl}` wires every seam at once: the rows, the loading
flag, external sort and filter, and the pager fed with the server's
count.
```svelte
{requestLog[0] ?? 'loading'}{view?.total !== undefined ? ` ยท ${view.total.toLocaleString()} rows on the server` : ''}
```
Sort by Amount, filter Country, turn a page: each is one request with
`startRow`, `endRow`, `sortModel` and `filterModel` on it, and the
server's `rowCount` is what the pager counts. The grid holds 25 rows.
## Infinite scroll
`mode: 'infinite'` drops the pager: the scrollbar spans the whole result,
blocks of `blockSize` rows load as the viewport reaches them, and
placeholder rows stand in for the rest. `maxBlocksInCache` puts an LRU
cap on the blocks kept, so the memory stays flat however far someone
scrolls; without it every loaded block stays. The server is unchanged.
```svelte
{requestLog[0] ?? 'loading'}
```
Drag the scrollbar to the bottom: the last block loads first, the ones
above it as you pass them. [Server-side infinite scroll](https://svgrid.com/docs/help/server/server-infinite-scroll/)
covers the cache, retries and the unknown-count mode.
## Group on the server
Grouping a hundred thousand rows in the browser means shipping them
first. `createServerRowModel` from `@svgrid/enterprise` sends `groupBy`
and `groupKeys` instead: the server answers a top-level request with one
row per region carrying its sums, an expand with the countries under
that region, and a second expand with the raw rows. The model keeps a
block cache per level; the grid holds what is open.
The group column is a column like any other, drawn by `SvGroupCell`
(the expander, the indent, the count) with `serverGroupText` as the text
behind it for copy and export. `grandTotalRow` asks the server for the
totals over everything (`needsGrandTotal` on the request) and pins them.
```svelte
{requestLog[0] ?? 'loading'}
```
Open EMEA, then Germany: two requests, each with a longer `groupKeys`,
and the log line says what the server was asked. Sort by Amount and the
groups reorder on the server, since a sorted level is a sorted query.
The pinned row at the bottom is the grand total the server computed over
every row it holds.
## Let the user choose the groups
`SvRowGroupPanel` is the chip bar: its Group by select adds a column,
the chips reorder by drag or Alt+Arrow, and each chip has a close.
`setGroupBy` on the model is what it calls, and the model refetches from
the top with the new `groupBy`. The columns and the cache are the model's business,
so the panel and the grid stay one line each.
```svelte
ctl.setGroupBy(g)} />
```
Add Product, then drag it ahead of Region: the tree rebuilds from the
server each time, and `groupFooters` puts a subtotal row under every
expanded group. `applyMode="deferred"` on the panel batches the chips
behind an Apply button for a backend where each regroup is expensive.
> Live demo: Server grouping (row model) - https://svgrid.com/demos/496-server-grouping-model/
## An edit becomes a transaction
A leaf edit is one `updateRow` on the source, applied back into the
loaded level as a transaction, without a refetch. The group above it
does not know its subtotal changed, so the edit handler refreshes that
one route: a targeted `refresh({ route })`, not the tree.
```svelte
```
Double-click an Amount under APAC and change it: the cell flashes, the
server row is updated, and the APAC subtotal above it is fetched again.
`createRow` and `deleteRow` are the same shape, and
[transactions](https://svgrid.com/docs/help/server/server-transactions/) covers the feed case, where the
server pushes rows the grid did not ask for.
## A selection that is a rule
With rows the grid has never seen, "select all" cannot be a list of ids.
`selection: { groupSelects: 'descendants' }` makes the model keep a rule
instead, "everything, except these", per group, and the checkboxes read
and write it. `getSelectionState()` returns the rule as plain data, for
a bulk edit the server applies by rule (`updateWhere` on the source) or
a selection that survives a reload.
```svelte
rule: {rule}
```
Tick the header checkbox, then untick Germany: the rule reads
"everything, and within EMEA everything except Germany", a
`selectAllChildren: false` under the EMEA key. A bulk edit sent with
that rule reaches the rows it covers on the server, loaded or not; the
grand total row is the server's total and does not follow the
selection. The [selection page](https://svgrid.com/docs/help/server/server-selection/) has both rule
shapes and the bulk edit.
## What the grid never did
Sort a column and the server sorted; filter, and the server filtered;
open a group, and the server grouped. The grid held a few hundred rows
through all of it. That is the whole idea, and the rest of the row model
is more of the same request: `treeData` for a hierarchy loaded on expand
([tree data](https://svgrid.com/docs/help/server/server-tree-data/)), `pivotBy` and `pivotMode` for a
pivot the server computes ([pivot](https://svgrid.com/docs/help/server/server-pivot/)), and a
`planQuery` / `planToSql` pair that writes the SQL for any of them
([grouping](https://svgrid.com/docs/help/server/server-grouping/#you-probably-do-not-have-to-write-that)).
> Live demo: Server-Side Row Model: 1,000,000 rows - https://svgrid.com/demos/467-server-row-model-1m/
## See also
- [Server-Side Row Model](https://svgrid.com/docs/help/server/server-row-model/) - the request and the result, field by field, and the SQL translation.
- [Server grouping](https://svgrid.com/docs/help/server/server-grouping/) - level params, footers, refresh and retry per route, paging over the tree.
- [Server transactions](https://svgrid.com/docs/help/server/server-transactions/) - rows the server pushes.
- [Server selection](https://svgrid.com/docs/help/server/server-selection/) - the rule shapes and `updateWhere`.
- [Server row model: CRUD](https://svgrid.com/demos/482-server-crud/) - the demo with the full write side.
---
SvGrid is the Svelte 5 data grid (`npm install @svgrid/grid`, MIT). This page: https://svgrid.com/docs/help/server/row-model-walkthrough/ . All docs: https://svgrid.com/llms.txt