A Grid Separates Row-Data Array from a View-State Config Object

A Grid Separates Row-Data Array from a View-State Config Object

Rendering a data grid needs two distinct structures, kept separate:

  1. Row-data array — the backend payload: an array of row objects whose keys are the columns (see Grid Columns Are Row-Object Keys Projected into Augmentable Descriptors). Pure data, no UI concerns.
  2. Config / "list" object — the augmented column descriptors plus all cross-cutting view-state:
    • which columns are active / displayed
    • errors detected across rows
    • filters per column
    • sort order per column
    • groups of columns

The config object is derived from the data shape but owns every UI concern; the data array stays a clean projection of the backend. This split keeps the payload reusable and serializable while view-state evolves independently — the same separation-of-projection-from-state idea as Stateless Editor Panel as Pure Projection.

Why it matters: mixing row data and view-state into one structure couples the backend contract to UI bookkeeping — every filter/sort/error mutation would touch the data payload. Two structures let the grid recompute view-state without ever mutating the rows.