table: When should data be a table?

Comparing task names, status and owners suits a table. sort and select are registered events; whether sorting triggers a query depends on the application binding. Local display order is not evidence of a database update.

Start with these properties

columns defines the columns: key selects a field from each record, label supplies its heading, and align controls alignment. rows supplies the records. Field names connect these parts; screen position does not.

sort expresses a sorting intent and select a row selection. Applications can connect them to query or view operations; a header click does not establish a database change.

Read a structural example

From the source registry. This is structural reading material, not a live demo; referenced resources and actions require an application.

{
  "id": "user-table",
  "type": "table",
  "props": {
    "columns": [
      {
        "key": "name",
        "label": "Name"
      },
      {
        "key": "email",
        "label": "Email"
      },
      {
        "key": "role",
        "label": "Role",
        "align": "center"
      }
    ],
    "rows": [
      {
        "name": "Alice",
        "email": "alice@co.com",
        "role": "Admin"
      },
      {
        "name": "Bob",
        "email": "bob@co.com",
        "role": "User"
      }
    ]
  },
  "events": {
    "select": {
      "exec": "/users/.actions/view",
      "args": {}
    }
  }
}

For example, the name key reads Alice or Bob, while the label Name appears in the header. role: "Admin" is table data here, not a grant of administrator authority. The select event connects to a view action; this snippet does not expand how that handler receives the selected record.

Read the table reference.