Configurator API

The built-in configurator can be used through PivotPlugin, but it is also available as a standalone API. Use this when you want the field panel in a custom shell, sidebar, or framework-managed layout.

Main Entry Point

1
import { definePivotConfigurator } from '@revolist/revogrid-enterprise';

definePivotConfigurator(el, config, actions) mounts the configurator into any element.

Example

1
definePivotConfigurator(container, pivotConfig, {
2
  onUpdateColumns: (columns) => {
3
    pivotConfig = { ...pivotConfig, columns };
4
  },
5
  onUpdateRows: (rows) => {
6
    pivotConfig = { ...pivotConfig, rows };
7
  },
8
  onUpdateValues: (values) => {
9
    pivotConfig = { ...pivotConfig, values };
10
  },
11
});

`PivotConfigurationActions`

The current callback surface is:

onUpdateColumns
onUpdateRows
onUpdateValues

These callbacks receive the new ordered configuration for the edited zone.

What The Configurator Does Not Own

The configurator does not:

execute Pivot by itself
persist state for you
own the grid instance

It is purely a configuration UI. You decide where the updated state goes next.

Embedded Via `PivotPlugin`

When hasConfigurator is enabled on PivotConfig, PivotPlugin internally uses the same standalone configurator surface and wires it to pivot-config-update.

That means:

standalone usage and plugin-managed usage stay conceptually aligned
examples built around the standalone API still apply to plugin-managed usage

Visibility And i18n

The configurator reads:

showRows
showColumns
showValues
i18n

These options let you tailor the panel for a simpler or more controlled layout.

Best Practices

Keep the configurator state source-of-truth in one place, usually the same state object you pass to the grid.
Provide stable dimensions metadata so labels and aggregators stay consistent.
Persist the resulting PivotConfig rather than trying to persist the configurator UI separately.