This section introduces the Server-side Row Model with lazy loading of data fetched through an infinite scroll.
As a gentle introduction to the Server-side Row Model, this section will cover the simplest use case of infinite scrolling without any grouping, filtering, sorting or pivoting.
Enabling Server-side Row Model
By default the grid will use the Client-side Row Model, so
to enable the Server-side Row Model define the
rowModelType as follows:
Implementing the Server-side Datasource
The previous section outlined the interfaces associated with the Server-side Datasource.
The following snippet outlines how to implement a
ServerSideDatasource and then register it with the grid:
At the heart of the Server-side Row Model lies the Server-side Cache. When there are no row groups, like in the example covered in this section, a single cache will be associated with the root level node.
When the grid loads it will retrieve an initial number (as per configuration) of blocks containing rows. As the user scrolls down, more blocks will be loaded via the server-side datasource.
The following illustration shows how the grid arranges rows in blocks which are in turn contained in a cache:
To control the browser memory footprint, server-side blocks and their containing caches are lazy-loaded, and can be configured to purge automatically or manually via API calls.
When infinite scrolling is active, this says how many rows beyond the current last row the scrolls should allow to scroll. For example, if 200 rows already loaded from server, and overflowSize is 50, the scroll will allow scrolling to row 250. Default is 1.
How many requests to hit the server with concurrently. If the max is reached, requests are queued. Default is 1, thus by default, only one request will be active at any given time.
How many blocks to cache in the client. Default is no limit, so every requested block is kept. Use this if you have memory concerns, so blocks least recently viewed are purged. If used, make sure you have enough blocks in the cache to display one whole view of the table (ie what's within the scrollable area), otherwise it won't work and an infinite loop of requesting blocks will happen.
How many rows to initially allow the user to scroll to. This is handy if you expect large data sizes and you want the scrollbar to cover many blocks before it has to start readjusting for the loading of additional data.
How many rows for each block in the cache.
When enabled, closing group row nodes will purges all caches beneath closed row nodes. This property only applies when there is Row Grouping.
When enabled, always refreshes top level groups regardless of which column was sorted. This property only applies when there is Row Grouping.
Example - Infinite Scroll
The example below demonstrates infinite scrolling along with some of the above configuration options:
- Enabling Server-side Row Model: via the grid options property:
rowModelType = 'serverSide'.
- Lazy-loading: with the grid options property:
cacheBlockSize = 100data will be fetched in blocks of 100 rows at a time.
- Auto Purge Cache: to limit the amount of data cached in the grid you can set
maxBlocksInCachevia the gridOptions.
Continue to the next section to see how to lazy load data with: Row Grouping.