When the underlying data is changed for the grid, you can get the grid to refresh. The easiest way is to call api.refreshView(), which will refresh the entire table. Refreshing the entire view works very fast - this is in fact what is getting done as you are scrolling over large data - the DOM is been constantly redrawn with the rows as they come into the viewable area.

Even with lightening speed, this may not be what you want, as this will loose any context or state you may have in any of your cells. This can be a problem if a) the cell required time to build, such as requiring data from the server, and rebuilding such a cell would cause a visible redraw on the screen or b) the cell has a state or context, such as the cell is currently being edited, or the cell has been interacted with in some way that deviates it from the default initial representation.

This section goes through the options available as an alternative to calling api.refreshView().

If you are using AnguarJS to build your cells, then you may be benefiting from two-way-binding. If you are, then you might be wondering what all this refresh rubbish is all about and do you need it? Well if you are happy with what you have, that's totally fine, you can keep it. It is the authors opinion to avoid two-way-binding inside a grid as it gives poor performance, especially when displaying large amounts of data and virtualising the rows. There are lots of ways to refresh, each achieving the similar effects. Each refresh will either: rip out and replace the entire row, rip out and replace the particular cells, or call 'refresh' on the cellRenderer (see section on cell renderers). Which you use is up to you, there is not clear advantage, the different ways are provided to give you choice. Choose what fits into your application design the best.

Refreshing Everything, Specific Rows or Specific Cells

To refresh the grid, you can choose between the following options:

  • refreshView(): Rips out every virtual row and draws it again.
  • refreshRows(rowNodes): Rips out the virtual rows showing representing the provided list of row nodes and then redraws them.
  • refreshCells(rowNodes, colIds): Gets the individual cells for the provided rowNodes to refresh, the row itself and all other cells stay intact.

The grid below shows the above three options in action. The grid's columns 'Make' and 'Model' have cellRenderers that also display the timestamp the cell was rendered, so you can see when the cell is rendered again. Notice the following:
  • Refresh All -> All cells get refreshed.
  • Double Jillian -> Jillian's rows get completely refreshed.
  • Double Niall -> The 'Price' column only in Niall's rows get refreshed.

Refresh via rowNode

Each data item in ag-Grid is wrapped by a rowNode. The rowNode has two methods for refreshing that that it is wrapping:

  • setData(newData): Sets new data.
  • setDataValue(colKey, newValue): Sets just one value for a particular piece of data, using either the field specified in the colDef, or a valueSetter if provided.
Use the above if your code if working directly with the rowNode makes more sense for your code.

Volatile Cells

In addition to the api.refreshView() call, there is also a similar api.softRefreshView() call. The soft refresh differs in the following ways:

  • The rows are left intact, only the contents of the cells are redrawn.
  • Only cells marked as volatile are redrawn.
  • Classes and styles (including class rules) are reapplied to the cell.

Cells are marked as volatile by setting the attribute on the column definition.

Volatile Cells Example

The example below shows refreshing in action. The weekday columns are editable. As you edit the cells, the numbers on the right has side change. The volatile summary change as the cells change, as the columns are marked as volatile and the grid onCellValueChanged() function is calling api.softRefresh()

Note that the class rules are reapplied as the total and value change, marking the value as bold and red it if goes above the threshold.

Cell Refresh from Inside

You can request a cell to be refreshed from within by calling the params.refreshCell() function passed to the cell renderer. This is handy if the cell wants to refresh itself and / or get the cell style rules reapplied.

This can be handy if the cell gets itself into a state it wants to get out for. For example, you could have your own custom editing, and when the data has finished editing, you cal 'refreshCell()' will is a handy way to get the grid to rip the cell out and put it back again to the fresh 'non-editing' state.

Refresh Headers and Footers

If you call api.recomputeAggregates(), all header and footer rows will subsequently get ripped out and redrawn to show the new aggregate values. If you want to refresh all headers and footers without recomputing the aggregates, you can call api.refreshGroupRows() - useful if you want to refresh for reasons other than the aggregates being recomputed.

Headers, Footers and Cell Refresh Example

The example below demonstrates the following features:

Cell Refresh: As you hit + and - below, the containing cell updates the record and calls api.refreshCell(). This gets the cell to redraw and have it's css rules reapplied - marking the cell as red if the value goes above a threshold.

Aggregate Refresh: As the values change, the table is also recomputing the aggregates, which in turn get redrawn.