Skip to main content
Version: 1.0.4

Table

A data table that stays responsive over large result sets. Bound to a named query it is the standard way to put database rows on a screen.

The Table component as it renders with its default settings.The Table component as it renders with its default settings.

Reach for it when you need:

  • Order lists, batch records, downtime logs
  • Any query result with more than a few rows

Component name: Table · Category: Display

In the palette: Data table that stays fast over large result sets

Properties

Any property can be bound to a tag, another component's property, or a query.

PropertyTypeDefaultDescription
dataarray[{"id":1,"name":{"value":"Item 1","fontWeight":"bold"},"stat… (truncated)Array of row objects. A cell can be a plain value OR an object for per-cell styling: { value, color, backgroundColor, fontSize, fontWeight, fontStyle, textDecoration, fontFamily }. A row-level 'backgroundColor' colors the whole row. Example: { status: { value: "Overdue", color: "#fff", backgroundColor: "#dc2626", textDecoration: "underline" } }
columnsarray[]Custom column definitions and overrides.
freezeColumnsarray[]List of column IDs to fix to the left side.
enableReorderbooleanfalseLet users drag column headers at runtime to reorder them. Pinned columns (row selection checkbox, edit/delete actions, frozen columns) stay in place — only the center group is reorderable.
groupsarray[]Hierarchical column grouping definitions.
searchobject
paginationobject
zebraStrippingobject
rowSelectionobjectLet users select rows. Adds a pinned checkbox column (stays left even with frozen columns). Selection is exposed at runtime as {{ <tableName>.selectedRowIds }} and {{ <tableName>.selectedRows }}.
rowActionsobjectPer-row Edit/Delete buttons pinned on the right. Each button fires a Table event (rowEdit / rowDelete) with the clicked row as script context — wire them in the Events dialog (Edit → open a form, Delete → run a delete named query: a SQL DELETE or a MongoDB delete op). No inline editing.
selectedRowIdsarray[]Output (bind from this): ids of the selected rows. Always reliable across paging/sort.
selectedRowsarray[]Output (bind from this): the selected row objects (currently-loaded rows).
emptyMessagestringNo data available
stylestyle{}Custom CSS properties

Events

Attach event actions to these in the Event Manager.

EventLabelGroupPayload
clickClickMouseThe DOM event.
dblclickDouble clickMouseThe DOM event.
contextmenuRight clickMouseThe DOM event.
mouseenterMouse enterMouseThe DOM event.
mouseleaveMouse leaveMouseThe DOM event.
rowClickRow clickTableThe clicked row, as row.
rowDoubleClickRow double clickTableThe clicked row, as row.
selectionChangeSelection changeTableThe current selection.
rowEditRow editTableThe edited row.
rowDeleteRow deleteTableThe row to delete.
cellClickCell clickTable
cellDoubleClickCell double clickTable
Right-click behaves differently in the Designer

contextmenu fires your configured actions at runtime only — in LiveView and in preview. On the Designer canvas the right-click is captured to open the Event Manager, so testing it there will not run your actions. Test right-click in preview.

Notes

Its row events carry the clicked row, which makes drill-down a one-action affair: rowClick → navigate("detail", { id: row.id }).

Columns are addressable parts. A column can carry its own cellClick and cellDoubleClick, wired in the Event Manager under the column id — the same id used everywhere else in the Table's configuration — so one column can drill down where the rest of the row does nothing. Rows deliberately are not addressable: a query can produce thousands of them, so branching on one stays a rowClick with an Only when… guard. → Events on a part of a widget

Page or limit the query. An unbounded table binding is the usual cause of a LiveView session growing over a shift.

See also