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:
- 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.
- 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.