Data can be updated inside the grid using the grid's API.
The grid also allows updating data in the following other ways which are explained in other sections of the documentation:
This section of the documentation is regarding using the grid's API to update data. The grid will then be aware of the change and also update the relevant parts of the UI.
If you are using an immutable data store, as is usual in a React application, then you will be interested in the section below Bulk Method 3 - Delta Row Data.
You can set the data onto a rowNode directly using the rowNodes API methods:
Updating via the rowNode methods is supported in all row models.
Updating data via the rowNode methods will refresh the grid for the required rows if they are showing, however it will not update the grids sorting, filtering or grouping if the new data impacts such. For that, you should use an update transaction as explained below.
If you are using In Memory Row Model
and you want to get the grid to update it's sort or filter etc after the update
is done, then you must call
where step can be one of the following: group, filter, map, aggregate,
The example below demonstrates the following:
If you want to update more than one row at a time, then you have the following options:
Method 1 - Transaction
The first method is to pass a transaction object to the grid containing rows to add, remove
and update. This is done using
api.updateRowData(transaction). The grid keeps
all active sorting, grouping and filtering, including updating to reflect the changes in
the data should the sorting, grouping or filtering be impacted.
Updating using transactions is the best way to do large updates to the grid, as the grid treats them as delta changes, so the grid only refreshes what is needed giving a performance boost. All row and range selection will be kept.
Method 2 - Row Data (Normal)
The next way is to replace all the row data in the grid be calling
or by binding new data to the
rowData property (if using a framework such as Angular or
React that allow data binding). This is the default method. The grid will discard all previous
data and create the rowNodes again from scratch. All row and range selection will be lost.
Use this method if you are effectively loading brand new data into the grid, eg loading a new report with a completely different data set to the previous. This makes sure nothing is lying around from the old dataset.
Method 3 - Delta Row Data
The final method is using the row data method above but having the property
When deltaRowDataMode is on, the grid will compare the new row data with the current row data and create a transaction object for you. The grid then executes the change as an update transaction, keeping all of the grids selections, filters etc.
Use this if you want to manage the data outside of the grid (eg in a Redux store) and then let the grid work out what changes are needed to keep the grid's version of the data up to date.
api.updateRowData(transaction) takes details of what data items to update
and then returns all the impacted row nodes.
The grid will create one new row for each item in the
The grid will remove one row for each item in the
If you are providing rowNode ID's (via the
getRowNodeId() callback) then the
grid will match the rows based on ID. If you are not using ID's, then the grid will match
the rows based on object reference.
The grid will update one row for each item in the
Behind the scenes, the grid will call
Similar to removing, the grid will use node ID's if you are providing your own ID's, otherwise it will use object reference to identify rows.
The In Memory Row Model fully supports the
api.updateRowData() call. The
Infinite Row Model supports 'add'
only (see the infinite docs for examples). The
Viewport Row Model and
Enterprise Row Model do not support
The example uses the
updateRowData method in different ways and prints
the results of the call to the console. The following can be noted:
When using transactions and grouping, the groups are kept intact as you add, remove and update rows. The example below demonstrates the following:
Things to try with the below example include:
This is the simplest of the update methods. When you call
the grid discards all previous selections and filters, and completely overwrites the old data
with the new. This was the first way the grid worked and is the most 'brute force' way.
Use this method if you want to load the grid with a brand new set of data.
api.setRowData() works with the
In Memory Row Model only. All of the other
row models use a data source and hence it doesn't make sense.
If you turn on deltaRowDataMode (set the property
then when you call
api.setRowData(rowData) the grid will work out which
items are to be added, removed and updated.
The deltaRowDataMode is designed to allow ag-Grid work with immutable stores such as Redux. In an immutable store, a new list of rowData is created if any row within it is added, removed or updated. If using React and Redux, consider setting deltaRowDataMode=true and bind your Redux managed data to the rowData property.
You can also use this technique in a non-Redux or immutable store based application (which is the case in the examples on this page). As long as you understand what is happening, if it fits your applications needs, then use it.
For the deltaRowDataMode to work, you must be providing ID's for the row nodes by
The grid works out the delta changes with the following rules:
The example below shows the immutable store in action. The example keeps a store of data
locally. Each time the user does an update, the local store is replaced with a new store
with the next data, and then
api.setRowData(store) is called. This results
in the grid making delta changes because we have set
If using React and Redux, simply map the store to the
rowData property instead
The example demonstrates the following:
*assuming when no sort applied - because if the grid is sorting, then the grid sort will override any order in the provided data.
Finally, lets go bananas with delta updates. Below is a simplistic trading hierarchy with over 11,000 rows with aggregations turned on. It has the following features:
This example is best viewed in a new tab. It demonstrates a combination of features working together. In particular you should notice the grid is managing a very large set of data, applying delta updates to the data and only updating the UI where the updates have an impact (as opposed to recalculating everything from scratch when new values come in an requiring a full grid refresh). This gives a fast smooth user experience.
You should also notice that all row selections, range selections, filters, sorting etc work even though the grid data is constantly updating.
If you want the grid to flash the cell when the data changes, set attribute
colDef.enableCellChangeFlash=true. In the example below, when you click
'Update Some Data', the data is changed in 20 random cells and the grid flashes the cells.
Each time the call value is changed, the grid adds the CSS class
for 500ms, and then then CSS class
ag-cell-data-changed-animation for 1,000ms.
The grid provide themes use this to apply a background color (for the first 500ms) and then a fade
out transition (for the remaining 1,000ms).
If you want to override how the flash presents itself (eg change the background color, or remove the animation) then override the relevant CSS classes.