This section covers the Server-side Cache and configurations available in the Server-side Row Model.
As many of the configurations available in the Server-side Row Model relate to the Server-side Cache it important to understand how the grid organises data obtained from the server into caches.
At the heart of the Server-side Row Model lies the Server-side Cache. There is a cache containing the top level rows (i.e. on the root node) and for each individual Row Grouping level.
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 into 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.
Applications can fine tune the Server-side Row Model based on specific application requirements using the following configurations:
|How many rows for each block in the cache, i.e. how many rows returned from the server at a 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, and block that were least recently viewed will be purged when the limit is hit. If used, make sure you have enough blocks in the cache to display one whole view of the table (i.e. what's within the scrollable area), otherwise it won't work and an infinite loop of requesting blocks will happen.|
|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 |
|How many requests to hit the server with concurrently. If the max is reached, requests are queued.|
|Prevents blocks loading until scrolling has stopped for the specified number of milliseconds. When row count (i.e. lastRowIndex) is known, setting this property will enable skipping over blocks when scrolling.|
|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 re-adjusting for the loading of additional data.|
|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.|
When experimenting with different configurations it is useful to enable debug mode as follows:
The screenshot below is taken from the browsers dev console when
debug is enabled:
Notice that the current cache status is logged showing block details such as the
This can be very useful when debugging issues on the server.
Example: Block Loading Debounce
The example below demonstrates a number of the configurations listed in this section and shows how adding a debounce to block loading allows for quick scrolling over rows. Note the following:
cacheBlockSize=200- fetches 200 rows per request instead of 100 by default.
maxBlocksInCache=10- once a cache contains 10 blocks the oldest blocks will be purged to ensure the cache is constrained to 10 blocks. By default all blocks are kept.
blockLoadDebounceMillis=100- loading of blocks is delayed by
100ms. This allows for skipping over blocks when scrolling to advanced positions. Note that the last row index should be supplied in
successCallback(rows, lastRow)so that the scrollbars are sized correctly.
debug=true- open the browsers dev console to view the cache status and block details.
Continue to the next section to learn about Server-side Sorting.