Client-Side Row Model

Client-Side Data means all 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 Row Models that can be used
where data is mostly kept on the server and loaded into the grid in parts.

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.

Updates vs Edits vs Refresh

This page talks about updating data via the grid’s API. It does not talk about the following:

  1. Editing data inside the grid using the grid’s UI, for example by the user double-clicking on a cell and editing the
    cell’s value. When this happens the grid is in control and there is no need to explicitly tell the grid data has
    changed. See Cell Editing on how to edit via the grid’s UI.
  2. The grid’s data is updated from elsewhere in your application. This can happen if you pass data to the grid and then
    subsequently change that data outside the grid. This leaves the grid’s view out of sync with the data that it has.
    In this instance what you want to do
    is View Refresh to have the
    grid’s UI redraw to display the data changes.

Updating Data

Updating data in the grid can be done in the following ways:

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 updating the Grid property rowData.

The grid takes a Transaction containing rows to add, remove and update. This is done using the Grid
property rowTransaction.

Updating rowData

Update the Row Data inside the grid by updating the rowData grid property

When providing a new data set through the Grid property rowData, the Grid has two different behaviors
whether Row IDs are provided or not.

Function Row IDs Missing Row IDs Provided
Row Refresh All rows destroyed from the DOM and recreated, flicker may occur. Only changed rows are updated in the DOM.
Row Animation No row animation. Moved rows animate to new position.
Flashing Cells No flashing available, all cells are created from scratch. Changed values can be flashed to show change.

In both cases, the order of the rows will be the same as the new data set provided. But when the Row IDs are set, as the
existing rows are kept, they will be moved if needed. This behavior can be suppressed by using the parameter:

dashGridOptions = {'suppressMaintainUnsortedOrder': True}

This can be useful if the rows are draggable for example, to be able to update the data keeping the order defined by the
user. This also allows to have a performance boost as the rows are not reordered.

Note that if a grid sort is applied, the grid sorting order gets preference to the order of the new data set.

Example 1: Row IDs are not set

This first example shows the behavior of the Grid when Row IDs are not provided. Note the following:

Example 2: Row IDs are set

This second example shows the behavior of the Grid when Row IDs are provided. Note the following:

How It Works

When providing Row IDs, the grid works out what changes need to be applied to the grid using the following rules:

Comparison to Transaction Updates

When setting Row Data and not providing Row IDs, the grid rips all data out of the grid and starts from scratch with the
new Row Data.

However, when providing Row IDs and updating Row Data, the grid creates
a Transaction Update underneath the hood. In other
words, once the grid has worked out what rows have been added, updated and removed, it then creates a transaction with
these details and applies it. This means all the operational benefits to Transaction Updates equally apply to setting
Row Data with providing Row IDs.

There are however some differences with updating Row Data (with Row IDs) and Transaction Updates. These differences are
as follows:

For the reasons mentioned above, if you have large data sets (thousands of rows) and are looking for ways to make things
go faster, consider using Transaction Updates.

If you have smaller data sets (hundreds of rows) then everything should work without any noticeable lag.

Transaction Updates

Transaction Updates allow large numbers of rows in the grid to be added, removed or updated in an efficient manner. Use
Transaction Updates for fast changes to large datasets.

This is done using the Grid property rowTransaction providing a dictionary with the following keys:

To update using transaction, Row IDs must be provided, they will be
used by the Grid to match data provided in the transaction with data in the grid.

For updating rows, the Grid will find the row with the same ID and then swap the data out for the newly provided data.

For removing rows, the Grid will find the row with the same ID and remove it. For this reason, the provided records
within the remove array only need to have an ID present.

The following example shows how to add, add at a specific index, update and remove rows using Transactions.

Note that “Clear” and “Start Over” update entire dataset using rowData, but as explained
in Comparison to Transaction Updates as
the Row IDs are provided, underneath the hood, the Grid will use a Transaction to update the rows.