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 ModelThis 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 ModelThe 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 ModelThe 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 ModelWhich row model you use is set as a grid property rowModelType. Set it to one of 'clientSide',
'infinite', 'viewport', or 'serverSide'. The default is 'clientSide'.
Which row model you use will depend on your application. Here are some quick rules of thumb:
Here are more detailed rules of thumb.
Below is a quick 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.
The Client-Side row model does not need a datasource. Infinite, Viewport and Server-Side all use a datasource. The documentation on each row model type explains how to configure the datasource for the particular row model.