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:

• Updating rowData

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.

• Transaction Updates

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.

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:

• The data sets A and B are the same except that the set B inserts 2 new records and modifies the prices of the existing
  records.
• The Row Animation and Flashing Cells features are enabled, but have no effect while switching between the sets (but
  the animation works when dragging).
• Row dragging is enabled, dragging rows to have a custom order and switching between the sets will remove this custom
  order.
• Sorting the rows will have the preference over the sets order.

Example 2: Row IDs are set

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

• The data sets are the same as the previous example: the data sets A and B are the same except that the set B inserts 2
  new records and modifies the prices of the existing records.
• The Row Animation and Flashing Cells features are enabled and will have the desired effect while switching between the
  sets (but the animation works when dragging rows).
• Row dragging is enabled, dragging rows to have a custom order and switching between the sets:
  • Will remove this custom order if suppressMaintainUnsortedOrder: False (default)
  • Will keep this custom order if suppressMaintainUnsortedOrder: True , the new rows will be added at the end of
    the Grid.
• Sorting the rows will have the preference over the sets order.

How It Works

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

• If the ID for the new item doesn’t have a corresponding item already in the grid then it’s added as a new row to the
  grid.
• If the ID for the new item does have a corresponding item in the grid then compare the object references. If the
  object references are different, the row is updated with the new data, otherwise it’s assumed the data is the same as
  the already present data.
• If there are items in the grid for which there are no corresponding items in the new data, then those rows are
  removed.
• Lastly the rows in the grid are sorted to match the order in the newly provided list.

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:

• When setting Row Data, the grid will have the overhead of identifying what rows are added, removed and updated.
• When setting Row Data, the grid stores the data in the same order as the data was provided. For example if you provide
  a new list with data added in the middle of the list, the grid will also put the data into the middle of the list
  rather than just appending to the end. This decides the order of data when there is no grid sort applied. If this is
  not required by your application, then you can suppress this behaviour for a performance boost by setting
  dashGridOptions = {'suppressMaintainUnsortedOrder': True}.

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:

• add (list; optional) Rows to add
• addIndex (number; optional) Index to add rows
• remove (list; optional) Rows to remove
• update (list; optional) Rows to update

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.