syidaxgrid
Home Pricing Settings
SYIDAX / DATA GRID

Server-side row model PRO

Query grouped server data and load it according to expansion state.

Get started
Server-side row modelSample order data
120 rows
Loading Grid…
Latest result

Choose an expansion order such as Team → Region → Order, and implement server queries for each path.

View code
Current preview

Usage guide

#

Use this to browse large grouped data sets, such as orders by team. Expanding a group can fetch only that group's data.

Integration steps

  1. Define group paths

    Choose an expansion order such as Team → Region → Order, and implement server queries for each path.

  2. Connect the server data provider

    Connect serverSideDatasource to code handling group keys, sorting, and filters. Distinguish top-level group requests from requests within a group.

  3. Verify expansion and requerying

    Expand a group in your app and inspect its network request and result rows. Changing filters should update group counts and content under the same conditions.

Expected results

Users can explore expanded sections progressively without downloading every group's orders first.

This local table does not execute server group queries. Review response formats and callback contracts in the related API before integrating them.

Useful terms

Group key
A value such as Platform or APAC identifying which group is being queried.
serverSideDatasource
A connection object supplying group and row data from the server.

Using this feature in your product requires the Pro runtime and a valid license.

API reference

#

Other properties3
Attribute / PropertyType / DefaultDescription
PRO
serverSideDatasource		ServerSideDatasource<GridRow>Default: undefinedserver-side (SSRM) row model. When set, the server groups + paginates the data and the grid fetches one level at a time (`serverSideGroupCols` = the group columns, in order; empty = a flat server-side list). Reuses `cacheBlockSize` / `maxBlocksInCache` per node.
PRO
serverSideGroupCols		string[]Default: undefinedthe columns the server groups by, in order (empty = flat).
PRO
serverSideTransactionWaitMs		numberDefault: undefinedwait window (ms) for `applyServerSideTransactionAsync` batching (the AG `asyncTransactionWaitMillis` shape under our naming). Read when the async queue is FIRST built; defaults to 50.
Events1
EventsDetail typeDescription
PRO
SyGridServerStoreUpdatedDetailthe `storeUpdated` event at the element boundary.
Methods13
Method / ArgumentsReturn typeDescription
PRO
Promise<SyGridServerSelectionState>PG-SEL-WIRING-01 — the server-side selection state: one predicate (`selectAll`) plus the exception ids, grid-wide, held without materialising a single row. Under a row-grouped topology the grid runs the hierarchical model instead and this answers `model-mismatch` naming `getServerGroupSelectionState`.
PRO
Promise<SyGridServerSelectionState>PG-SEL-WIRING-01 — the hierarchical tri-state selection under a row-grouped SSRM topology.
PRO
input: unknown		Promise<SyGridServerSelectionSetResult>PG-SEL-WIRING-01 — replace the flat server selection state (`{ selectAll, toggledRowIds }`), typed refusals kept.
PRO
input: unknown		Promise<SyGridServerSelectionSetResult>PG-SEL-WIRING-01 — replace the hierarchical selection state (`{ selectAllChildren, toggledNodes }`).
PRO
action?: 'select' | 'clear'		Promise<SyGridServerSelectAllResult>PG-SEL-WIRING-01 — select (default) or clear the WHOLE grid, unloaded rows included, in O(1).
PRO
groupKeys: ReadonlyArray<string>, action?: 'select' | 'deselect'		Promise<SyGridServerGroupChildrenResult>PG-SEL-WIRING-01 — select or deselect ONE group subtree by its group-key path (group model).
PRO
input?: SyGridServerRefreshInput		Promise<SyGridServerRefreshResult>route-scoped SSRM refresh ` shape under our naming).
PRO
transaction: SyGridServerTransactionInput		Promise<SyGridServerTransactionResult>synchronous route-addressed server-side transaction . Order inside one transaction is pinned update → remove → add; `addIndex` addresses the post-remove sequence.
PRO
transaction: SyGridServerTransactionInput, onSettle?: (settlement: SyGridServerTransactionSettlement) => void		Promise<SyGridServerTransactionEnqueue>enqueue a server-side transaction into the async queue (the AG `applyServerSideTransactionAsync` shape under our naming). One wait window (`serverSideTransactionWaitMs`, default 50 ms) batches enqueues FIFO into one apply pass and ONE state commit; `onSettle` receives exactly one settlement, ever. State is read at FLUSH time , so a transaction enqueued before a refresh applies to the post-refresh store — or settles as a typed `store-loading` refusal.
PRO
Promise<SyGridServerFlushReport>apply the pending async batch NOW (the AG `flushServerSideAsyncTransactions` shape). `empty` when nothing is pending — including when the queue was never built, which is why this method never loads the chunk to say so.
PRO
Promise<SyGridServerStateReport | null>the readonly snapshot over every live store: route/type/status/counts and per-block cache state, deep-frozen, plus the cross-tree diagnostics (`nodesWithoutStore` — the PG-SSRM-ORPHAN-01 class made visible) and the facade's landing-guard counter.
PRO
Promise<SyGridServerPivotColumnsReport | null>the identity model over the pivot result metadata the store retains (root-store-only publishing). Identity is the server's own naming under its group path, encoded by the one codec — the same label under two parents is two identities , and a duplicate colId refuses the whole model with the ids named.
PRO
colIds: ReadonlyArray<string>		Promise<SyGridServerPivotColumnAudit | null>the PG-PIVOT-CONSUMER-01 usage gate: for the column ids a consumer is about to chart/export/restore against, answer `live` / `live-stale` / `unknown-column` from the CURRENT model, so after a metadata refresh no gated consumer uses a vanished column silently. `clean` is `true` iff every asked id resolved. `null` = SSRM is not active on this grid.
GridTab Navigate Enter Open