Expand All

  Getting Started



  Row Models




  Third Party


Github stars make projects look great. Please help, donate a star, it's free.
Get informed on releases and other ag-Grid news only - never spam.
Follow on Twitter

Row Models

The grid follows an MVC pattern. Each data item is wrapped in a Row Node and then stored in a Row Model. The grid rendering engine listens for changes to the row model and draws rows on the screen when the rows change (eg after a filter or a sort is applied).

Depending on your needs, the grid can be configured with different row models. The row models differ in how the data is loaded. You can load all the data and hand it over to the grid (In Memory Row Model) or you can keep most of the data on the server and lazy-load based on what is currently visible to the user (Infinite Scrolling, Viewport and Enterprise Row Models).

The following is a summary of the different row models:

  • In Memory: 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.
  • Infinite Scrolling: This will present the data to the user in one screen with a vertical scrollbar. The grid will retrieve the data from the server in blocks using a least recently used algorithm to cache the blocks on the client. Use this if you have a large (to large to bring back from the server in one go) and flat list (not grouped) of data that you want to show to the user.
  • Viewport: This will present the data to the user on screen with a vertical scrollbar. The 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, typically used for updates in live datastreams (as server knows exactly what each user is looking at).
  • Enterprise: Enterprise allows lazy loading of grouped data with server side grouping and aggregation with slice and dice capability. Use this if you want the user to experience grouping and / or aggregations that are done on the server side, or if you want the user to navigate very large datasets of grouped data, or you simple want to lazy load group data.

Light Overview of Row Model

Below shows a very cut down and simplistic class diagram of the interaction between the grid's rendering engine (RowRenderer) and the Row Models.

The following should be noted from the diagram:

  • The grid has exactly one RowRenderer instance. The RowRenderer contains a reference to the PaginationProxy where it asks for the rows one at a time for rendering.
  • The grid has exactly one 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.
  • You can configure the grid to use any of the provided Row Models - that's why RowModel is in italics, it means it's an interface, the concrete implementation is what you decide at run time. The RowModel contains a list of RowNodes. The RowModel may have a list of all the RowNodes (In Memory Row Model) or have a DataSource where it can lazy load RowNodes
  • A RowNode has a reference to exactly one row data item (the client application provides the row data items). The RowNode has state information about the row item, such as whether it is selected and the height of it.
  • When there is a change in state in the RowNodes, the RowModel fires a modelUpdates 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.

Row Model Comparisons

The following table compares the row models highlights.

Model Sorting & Filtering Grouping & Aggregation Server State** Availability
In Memory Inside the Grid Inside the Grid* Stateless ag-Grid (Free)
Infinite Scrolling Server Side No Stateless ag-Grid (Free)
Viewport Server Side No Stateful ag-Grid Enterprise
Enterprise Server Side Server Side Stateless ag-Grid Enterprise

* Grouping and Aggregation for the In Memory row model is available in ag-Grid Enterprise only.

** Server State means your server is aware of client state. For viewport, the server knows exactly what each user is currently looking at, whereas all other row models access the server is a stateless fashion.

Setting Row Model

What row model you use is set as a grid property. Set it to one of {normal, infinite, viewport, enterprise}. The default is normal.

When to Use

Which row model you use will depend on your application. Here are some rules of thumb:

  • If you are not sure, use default In Memory. The grid can handle massive (100k+) amounts of data. The grid will only render what's visible on the screen (40 rows approx???) even if you have thousands of rows returned from your server. You will not kill the grid with too much data - rather your browser will run out of memory before the grid gets into problems. So if you are unsure, go with In Memory row model first and only change if you need another. With In Memory, you get sorting, filtering, group, pivoting and aggregation all done for you by the grid. You can also provide your own filters, sorts and aggregation functions to customise these operations. All of the examples in the documentation use the In Memory model unless specifically specified otherwise.
  • If you do not want to shift all the data from your server to your client, as the amount of data is too large to shift over the network or to extract from the underlying datasource, then use on of viewport, infinite scrolling or enterprise. Each one takes data from the server in different ways.
  • Use Infinite Scrolling to bring back a list of data one block at a time from the server. As the user scrolls down (or progresses the pages using pagination) the grid will ask for more rows. This is the easiest way to present a large dataset to the user while only loading a subset from the server at any given time.
  • Use Viewport if you want the server to know exactly what the user is looking at. This is best when you have a large amount of changing data and want to push updates to the client when the server side data changes. Knowing exactly what the user is looking at means you only have to push updates to the relevant users.
  • Use Enterprise if you want to load large amounts of data that is grouped, or you want to allow the user to slice and dice data from the client. This is best used for reporting applications or other applications that need to present large amounts of hierarchical data.


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.

Grid Datasource

The In Memory row model does not need a datasource. Infinite Scrolling, Viewport and Enterprise all use a datasource. The documentation on each row model type explains how to configure the datasource for the particular row model.