# `table` — behaviour

*Open when a table paints skeleton rows that never resolve, loads nothing, or ships writable when you meant it read-only.*

**Who issues the request.** `kind: 'entity'` and `kind: 'static'` run the grid's own internal datasource. `suppaSql` and `aggregation` are host-owned: while that datasource is `null` the grid registers the dependency, paints skeleton rows and issues **no request at all**. A table has no datasource error state (unlike `chart`), so this is indistinguishable from slow. `loadOnMount` is ON unless exactly `false`.

**The skeletons that never end.** A `$param` in `sqlQuery` whose bound element is *empty* is treated as waiting for input, not broken — running it would 400 with `UNKNOWN_BIND_PARAM`, so the source is withheld. The gate catches only a `sqlParams.<p>.field` naming no element; an element that exists and is blank on first paint leaves the published table on skeletons until someone types. Give every element behind a `$param` a default value.

**Editing is on unless you turn it off.** `editing.inlineAdd`, `editing.deleteRow` and `editing.bulkActions` are ON when unset, so a table nobody configured creates and deletes records — and `confirmDelete` is OFF, so the delete is immediate. Only an entity source writes: on `suppaSql`/`aggregation` the write affordances are forced off at render, so editing keys that survived a kind switch stay in the schema and do nothing. Per column, `editor.enabled: true` cannot grant editing that the entity field forbids; it can only veto.

**Silent keys.** The manifest allow-list reaches top-level props only, so anything misspelled *inside* `dataSource` or `settings` passes `unknown_prop` untouched. Known no-ops: a column's `icon` (persisted, rendered by nothing) and the chart keys `sqlCategoryColumn` / `sqlValueColumns` on a `suppaSql` table — a table maps its result through `settings.columns` and reads neither.