Skip to content

Dimensions

A Pivot dimension is the reusable definition of a field. It tells Pivot what the field is called, how it should behave in generated headers, and which aggregators are valid when that field is used as a measure source.

Each dimension is a PivotConfigDimension. In practice it is a partial RevoGrid column definition plus Pivot-specific metadata.

const dimensions = [
{ prop: 'region', name: 'Region', sortable: true },
{ prop: 'quarter', name: 'Quarter' },
{
prop: 'sales',
name: 'Sales',
aggregators: {
sum: commonAggregators.sum,
avg: commonAggregators.avg,
},
},
];

prop is the source-of-truth field id. rows, columns, and values all refer back to these same prop values.

  • In rows, a dimension becomes part of the leading row hierarchy.
  • In columns, a dimension becomes part of the generated header hierarchy.
  • In values, the same field acts as the carrier for the aggregated measure.

This shared model is what keeps Pivot configuration consistent. You define a field once, then reuse it on whichever analytical axis makes sense.

PivotConfigDimension extends Partial<ColumnRegular>, so the most useful inherited options are:

  • prop: The field id Pivot uses everywhere.
  • name: Display label for generated headers and configurator entries.
  • sortable: Enables sorting of generated members for that dimension.
  • order: Initial sort direction for generated members when sorting is enabled.
  • filter: Filter metadata carried into generated columns.
  • columnType: Lets generated value columns reuse an existing column type.
  • template: Custom rendering for generated cells or headers.
  • cellProperties: Per-cell visual or behavioral overrides.
  • size, minSize, maxSize: Width behavior for generated columns.

The most important rule is that Pivot does not invent a second metadata model. Generated columns are still RevoGrid columns, and the dimension is where their base behavior comes from.

Dimensions also declare which aggregators are available when the field is used in values.

{
prop: 'margin',
name: 'Margin',
aggregators: {
sum: commonAggregators.sum,
avg: commonAggregators.avg,
max: commonAggregators.max,
},
}

This matters in two places:

  • values[].aggregator resolves against the dimension.
  • The configurator uses the dimension’s registered aggregators to populate its value selector.
  • Keep prop stable. Changing it breaks saved Pivot layouts.
  • Use business-friendly name values because generated headers reuse them.
  • Define aggregators only where they make semantic sense.
  • Avoid using display labels as identifiers. prop should be the identifier, name should be presentation.
  • Omitting a dimension for a field that later appears in values.
  • Registering an aggregator on a text field just because the function exists.
  • Expecting dimension order to control row or column placement. Placement is controlled by rows and columns, not by the dimensions array order.

Continue with Aggregations to see how measures are resolved from these dimensions.