Expand All

  Getting Started



  Row Models




  Third Party


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

Master / Slave

Grids can be configured such that events that happen in one are propagated to happen in another. When this is happening, the grid that is creating the event is called the master, and the grid that is consuming the event is called the slave.

Using master / slave, you can have two grids have synced columns, such that column changes in one grid will be reflected in another grid. This is useful if you have two grids, one above the other, and you want the two of them to remain synced with regards their columns.


To have on grid act as a slave to another, place its grid options in the 'slaves' array of the first.

gridOptionsSlave = {
    // some grid options here
gridOptionsMaster = {
    // some grid options here
    slaveGrids: [gridOptionsSlave]

It makes a bit more sense in the examples...


The events which are fired as part of the master slave relationship are as follows:

  • Horizontal Scroll
  • Column Hidden / Shown
  • Column Moved
  • Column Group Opened / Closed
  • Column Resized
  • Column Pinned

Event Propagation

When a grid fires an event, it will be processed by all the slaves to that grid. However if a grid is acting within the context of a slave, it will not fire an event. For example, consider the grids A, B and C where B is a slave to A and C is a slave to B (ie A -> B -> C). If A gets a column resized, it will fire the event to B, but B will not fire the event to C. If C is also dependent on A, it needs to be set up directly. This stops cyclic dependencies between grids if two grids are acting as slaves to each other.


The pivot functionality does not work with Master / Slave grids. This is because pivoting data changes the columns, which would make the master and slave grids incompatible, as they are no longer sharing the same set of columns.

Demonstration Example

Below shows two grids acting as master and slave to each other (ie both are registered as slaves to the other grid). The following should be noted:

  • When either grid is scrolled horizontally, the other grid follows.
  • Showing / hiding a column on either grid (via the checkbox) will show / hide the column on the other grid, despite the API been called on one grid only.
  • When a column is resized on either grid, the other grid follows.
  • When a column group is opened on either grid, the other grid follows.
The grids don't serve much purpose (why would you show the same grid twice???) however it demonstrates the features in an easy to understand way.

A Wee More Useful Example

So why the hell would you want to do this anyway??? It's great for aligning grids that have different data but similar columns. Maybe you want to include a floating footer with 'summary' data. Maybe you have two sets of data, but one is aggregated differently to the other.

This example is a bit more useful. In the bottom grid, we show a summary row. Also note the following:

  • The top grid has no horizontal scroll bar, suppressed via a grid option.
  • The bottom grid has no header, suppressed via a grid option.
  • sizeColumnsToFit is only called on the top grid, the bottom grid receives the new column widths as the slave.
  • Split Column Groups

    It is possible that you have column groups that are split because of pinning or the order of the columns. The grid below has only two groups that are split, displayed as many split groups. The master/slave also works here in that a change to a split group will open / close all the instances of that group in both tables.