Boards, Calendars & Timelines

Four components take the same records a table would show and arrange them by something other than row order — by card, by column, by date, by span. All four bind through the shared dataSource module.

gallery

A responsive card grid.

- type: gallery
  dataSource: { table: products }
  gridColumns: { mobile: 1, md: 2, lg: 3 }
  layout: masonry
  galleryCard:
    coverImage: '$record.photo'
    aspectRatio: '4:3'
    children:
      - { type: text, element: h3, content: '$record.name' }

kanban

A board grouping records into columns by a field value, with drag-and-drop between them.

- type: kanban
  dataSource: { table: tasks }
  kanbanGroupBy: { field: status }
  drag: { enabled: true }
  card:
    children: [{ type: text, content: '$record.title' }]
    footer: [{ field: assignee, format: avatar }, { field: due_date, format: short-date }]

calendar

A month, week or day calendar of date-bearing records. The field mappings sit at the top level — only click handling lives under calendarEvent and calendarInteraction.

- type: calendar
  dataSource: { table: bookings }
  dateField: starts_at
  endDateField: ends_at
  labelField: customer_name
  defaultView: week
  calendarInteraction: { timeSlotInterval: 30, showCurrentTimeIndicator: true }

data-timeline

A Gantt-style view of records that occupy a span rather than an instant. Its schema is deliberately minimal — dataSource plus props — and the field mappings are read from props:

- type: data-timeline
  dataSource: { table: phases }
  props:
    startField: starts_on
    endField: ends_on
    labelField: name
    groupBy: workstream
    defaultZoom: month

Note that data-timeline is the data-bound Gantt island; the plain timeline in Display Components is a static structural list with a rail, and takes no data source.

Colouring records by a field

kanban, calendar and data-timeline each accept a colorField naming the field whose value colours the card, event or bar. The three spell it differently, because the key sits wherever each component already keeps its display config:

The colour comes from the option colours declared on that field. Only single-select, multi-select and status carry option declarations, so only those three can supply one:

tables:
  - name: tasks
    fields:
      - name: priority
        type: single-select
        options:
          - { value: urgent, color: '#DC2626' }
          - { value: normal, color: '#2563EB' }

- type: kanban
  dataSource: { table: tasks }
  kanbanGroupBy: { field: status }
  card:
    colorField: priority # urgent cards fill #DC2626, normal cards #2563EB

Text is not left to chance: each surface derives a foreground from the fill — whichever of black or white contrasts more — so a label stays legible against any hue an author picks.

A multi-select resolves only while a record holds exactly one option. A cell holding two or more matches no single declaration and takes the no-colour path below.

When a value declares no colour

The fallback differs per surface, and the difference is deliberate rather than an oversight:

Where a palette hue is used, it is now derived from the value itself, so a given value always draws the same hue. A timeline previously assigned palette hues in order of first appearance, which meant a bar changed colour as you paged or filtered the records around it.

The fallback applies per value, not per field: a field that declares colours on some options and leaves others bare sends only the bare ones down this path.

Calendar: a coloured event is a block, not a dot

In month view a calendar renders a timed event as a small dot by default. A dot is mostly empty space, so a colour applied to it is close to invisible. An event that carries a colour therefore renders as a filled block instead; an event with no colour keeps the default dot.

Expect this as a visible layout change on any month-view calendar that sets colorField — day cells that used to hold lines of dots now hold bands of filled blocks.

Related Pages

• Tables & Lists — data-table, list, data-form.
• Charts & KPIs — aggregated visualizations.
• Data Binding — dataSource, filters, pagination.
• Interactions & Auto-Save — the actions these components invoke.
• Display Components — the non-data timeline.