Sapporta Grid

A data grid has two kinds of work to do. It must decide what sorting, selection, editing, and hierarchy mean, and it must put those decisions on a screen. Sapporta Grid keeps the two apart so that the behavior of a grid does not depend on the framework used to render it.

To maintain that separation, all of those decisions belong to the core—to the grid runtime and, at the table-aware level, the grid session. The React components can then stay near the surface, observing the state, rendering it, and passing interactions back down. Because they do not carry the policy themselves, a Svelte or plain-JavaScript view could sit in their place and inherit the same behavior.

That separation becomes the bottom layer, GridCore, which provides the runtime, the data-source contract, and a basic React view. Most grids need more than this bare foundation, so ColumnPreset builds on it with typed columns, editors, formatting, and copying. When the rows are registered Sapporta records, TGrid adds one more layer, connecting the same machinery to schema metadata, generated queries, lookups, saves, and record routes.

Which layer you reach for depends less on how the grid should look than on where its rows come from. Registered Sapporta records usually remain in a generated table screen or TGrid, where the server still owns authorization and row security. By contrast, data assembled by the application—a temporary set of rows, a calculation, or a bounded projection for one screen—belongs in GridCore, generally with ColumnPreset.