Skip to main content

Customize a data grid

Start with the data model, then add grid behavior intentionally. A maintainable grid configuration mirrors business meaning rather than treating every field as a generic text column.

Use typed columns​

final columns = [
  const FdcIntegerColumn(
    fieldName: 'order_id',
    label: 'Order ID',
  ),
  const FdcDateColumn(
    fieldName: 'order_date',
    label: 'Order Date',
  ),
  const FdcDecimalColumn(
    fieldName: 'amount',
    label: 'Amount',
  ),
  const FdcBooleanColumn(
    fieldName: 'paid',
    label: 'Paid',
  ),
];

See Column Types.

Enable editing only where it belongs​

Keep identifiers, calculated values, and system fields read-only. Let business input columns use their typed editors.

See Grid Editing.

Add filtering and sorting​

Use the grid's filter and sort UI when users need interactive query control. The resulting operations flow through the same dataset query pipeline used by programmatic filters and adapter-backed queries.

See Grid Filtering and Grid Sorting.

Add summaries for useful measures​

Use summaries for values that help users interpret the visible dataset, such as order totals or average values.

See Summaries.

Handle application actions through events​

Use grid callbacks for application-level behavior such as opening a detail screen, handling row activation, or responding to contextual actions.

See Events and Callbacks.

Theme at the right level​

Prefer an application-level FDC theme for shared visual language. Override individual grid settings only when a screen has a real local requirement.

See Theming.

Add Pro behavior where it fits​

Pro capabilities such as detail rows, layout persistence, and sparkline columns remain part of the same grid configuration model. Add them only when they improve the user workflow; the rest of the grid does not need to be reorganized around edition boundaries.