This section demonstrates refreshing rows in order to reflect changes at the source while using the Server-Side Row Model (SSRM).
It is advised to use Row ID's when using Server-Side Refresh. Row ID's allow the grid to retain row state between refreshes, such as row height, expanded state, and cell flashing.
The grid API refreshServerSide(params)
instructs the grid to start reloading all loaded rows for a specified group.
To ensure your grid reflects the latest data on your server, you can periodically instruct the grid to refresh all of the loaded rows (known as polling) or strategically refresh based on your applications requirements.
The following example provides a simple demonstration of the different behaviours of the refresh API, note the following:
enableCellChangeFlash
.Purge
checkbox enables the purge option in the API call, this causes all rows (and all row state except row selection state) to be reset when the refresh call is made, and replaced with loading rows.storeRefreshed
event is fired, and logged in the console.When using row grouping with refreshing you are required to provide a route parameter specifying the row group to refresh. When a row group is refreshed, only its direct child rows are refreshed. This means that in order to refresh the rows in a particular row group, you need to provide the parent of the rows to be refreshed as the route parameter.
The following example demonstrates how to refresh specified groups on the server, note the following:
refreshServerSide
API call.Canada
row group.2002
row group that belongs to the Canada
row group.storeRefreshed
event is fired, and logged in the console.Continue to the next section to learn how to use Single Row Updates with the SSRM.