Client-Side Data means all of the data you want to show is loaded inside the data grid in one go. The data is provided to the grid using the rowData
attribute in a list.
There are four Row Models in the grid, of which the Client-Side Row Model is one. The Client-Side Row Model is the one that uses the rowData
attribute.
The remaining three Row Models are Server-Side Row Models that can be used where data is mostly kept on the server and loaded into the grid in parts.
This section of the documentation describes how to work with data when using the Client-Side Row Model.
The grid can be configured with different strategies for loading row data into the grid, which are encapsulated into different Row Models. Changing which Row Model the grid is using means changing
the strategy the grid is using for loading rows.
The grid comes with four row models:
The Client-Side Row Model deals with client-side data. The Server-Side, Infinite and Viewport Row Models deal with server-side data. The following is a summary of each:
This is the default. The grid will load all of the data into the grid in one go. The grid can then perform filtering, sorting, grouping, pivoting and aggregation all in memory.
Go to Client-Side Row Model
This will present the data to the user and load more data as the user scrolls down. Use this if you want to display a large, flat (not grouped) list of data.
Go to Infinite Row Model
The Server-Side Row Model builds on the Infinite Row Model. In addition to lazy-loading the data as the user scrolls down, it also allows lazy-loading of grouped data with server-side grouping and aggregation. Advanced users will use Server-Side Row Model to do ad-hoc slice and dice of data with server-side aggregations.
Go to Server-Side Row (AG Grid Docs)
The grid will inform the server exactly what data it is displaying (first and last row) and the server will provide data for exactly those rows only. Use this if you want the server to know exactly what the user is viewing, useful for updates in very large live datastreams where the server only sends updates to clients viewing the impacted rows.
Go to Viewport Row Model (AG Grid Docs)
Which row model you use will depend on your application. Here are some quick rules of thumb:
Here are more detailed rules of thumb.
See the AG Grid docs Row Models section for a feature comparison of all the grid’s features across all four row models.
The grid follows an MVC pattern. Each data item is wrapped in a Row Node and then
stored in the Row Model. The grid rendering engine is called Row Renderer and
listens for changes to the row model and updates the DOM accordingly.
Below shows a simplified version of a class diagram showing the relationships between
the major classes involved with the row models.
The following should be noted from the diagram:
RowRenderer
instance. The RowRenderer
contains a reference to the PaginationProxy
where it asks for the rows one at a time for rendering.PaginationProxy
instance. The PaginationProxy
will either a) do nothing if pagination is not active and just forward all requests to the Row Model or b) do pagination if pagination is active. The PaginationProxy
has exactly one RowModel
instance.RowModel
is in italics, it means it’s an interface, the concrete implementation is what you decide when configuring the grid. The RowModel
contains a list of RowNodes
. The RowModel
may have a list of all the RowNodes
(Client-Side Row Model) or have a datasource where it can lazy-load RowNodes
.RowNode
has state information about the row item, such as whether it is selected and the height of it.RowNodes
, the RowModel
fires a modelUpdated event which gets the RowRenderer
to refresh. This happens for many reasons, or example the data is sorted, filtered, a group is opened, or the underlying data has changed.Pagination can be applied to any of the row model types. The documentation on each row model type covers pagination for that row model type.
There are many ways in which data can change in your application, and as a result many ways in which you can inform the grid of data changes. This section explains the different ways of how you can update data inside the grid using the grid’s API.
This page talks about updating data via the grid’s API. It does not talk about the following:
Updating data in the grid can be done in the following ways:
Row Data
The easiest way to update data inside the grid is to replace the data you gave it with a fresh set of data. This is done by either updating the rowData bound property (if using a framework) or calling api.setRowData(newData).
Transaction
The grid takes a transaction containing rows to add, remove and update. This is done using api.applyTransaction(transaction).
Use transactions for doing add, remove or update operations on a large number of rows that are infrequent.
If you are frequently updating rows (e.g. 5 or more updates a second), consider moving to High Frequency instead (achieved with Async Transactions).
async
to True in the rowTransaction({“async” :True}).Use Async Transactions for doing add, remove or update operations that are frequent, e.g. for managing streaming updates into the grid of tens, hundreds or thousands of updates a second.