Tables

Roadie has one table for working through records and one for reading a summary. Pick by what people do with the rows, then shape the columns so the same record reads the same way in a pane, in a dashboard, and on paper.

Choose by job

Signs you picked the wrong one

• A DataTable gains a search box or a pager. It has become a working list. Use a RecordTable.
• A RecordTable holds five rows nobody searches. Use a DataTable, or a List when each row opens something.
• A card grid gets sort controls. People are comparing, not browsing. Use a RecordTable.
• A dashboard card lists people or orders. Show the count in a StatTile and link to the pane that lists them.
• A table has one row. Show the values as a StatTile or a description list.

<RecordTable
  caption='Orders'
  data={orders}
  fields={fields}
  columns={columns}
/>

<DataTable
  caption='Orders'
  columns={columns}
  rows={allOrders} // 4,812 rows
/>

Records live in a Pane

Most RecordTables fill a Pane: the title in the header, the toolbar with its search above the rows in the body, and the pager in the footer. Keep the search in the table's toolbar, not in Pane.Search. The RecordTable page has a complete pane to copy.

Columns

• Describe the record once. Build its fields with recordFields, then build columns from them with tableColumns. A field's type decides how its values read, everywhere it shows. See Records model.
• One title column. Pin it with pin: true. A column with narrow: 'title', or else the first pinned text column, or else the first text column, reads as the row's title, in strong text.
• Numbers end-aligned. Number and money fields do this, and sort largest first.
• Money. currency where cents matter, an order total or a payout. compactCurrency for gross across events, where $118k reads faster than $118,400. A field with currencyKey names any currency that isn't dollars.
• Dates. Event and access dates read in the venue's zone through timeZoneKey, long with the weekday. Timestamps read in the reader's zone, medium with the time. See Date and time.
• Status as a Badge. Give an option field a status map of each key to its intent, chosen by meaning. It shows a small Badge in normal emphasis and sorts by each key's order.
• Ids in monospace. Order numbers, references, and promo codes, through font-mono in the column's cell.
• Give each column its place on a phone. Under 40rem the table lists its records. The title column takes narrow: 'title', one line under it 'description', and a status 'trailing'. Any 'detail' column turns rows into cards; keep it to three or four details. The rest stay in the wide table.
• Let the extras go first. Give columns people can do without a priority so they hide as the table narrows, 3 first, before it turns into list rows.
• Images lead. An image column, with kind: 'image', shows a thumbnail, leads a list row, and becomes a card's banner.
• Hide the rest. A view's layout.columns.hidden hides columns, and its order reorders them. Pinned columns stay first and shown.

Totals

• Add a totals row when the totals belong to columns, so people read down a column to its total: sold, gross, and capacity across events. For two or three headline numbers that don't map to columns, show StatTiles above the table instead.
• Total every record that matches, never just the page. A server sums the matches, and the totals follow the search and filters.
• A RecordTable shows its totals under the headings, since its last row is only the end of a page. A DataTable shows them in its footer, under every row, as an invoice does.
• The label, such as "Totals for 1,234 shows", goes in the title column. With no title, it takes the first column without a sum, so it never covers a total. RecordTable and DataTable follow the same rule.
• Add up counts and amounts only. Work a ratio out from the sums, such as total sold over total capacity, never by adding up or averaging each row's.
• See Totals on the RecordTable page and DataTable.

Table examples

Orders

A working list in its own box, newest first. The order number is the pinned title, in monospace through its cell, and the status reads as a Badge. Under 40rem each row shows the customer under the order number and the status on the end.

const customers = ['Mia Tran', 'Jack Ellis', 'Ava Nguyen', 'Noah Smith', 'Isla Brown', 'Leo Wilson']
const eventNames = ['Ochre Kite Weekender', 'Marzipan Thunderclap', 'Corduroy Lagoon Sessions', 'Velvet Dingo Fest']
const statuses = ['paid', 'paid', 'paid', 'pending', 'refunded']
const orders = Array.from({ length: 60 }, (_, index) => ({
  id: `order-${index}`,
  number: `OZ-${48210 + index * 7}`,

Top events in a dashboard

A DataTable in a DataCard. Five rows, sorted by gross, with the venue as secondary text and sell-through as a meter.

<div className='w-full max-w-md'>
  <DataCard
    label='Top events'
    takeaway='Ochre Kite Weekender leads gross this month'
    source='Oztix sales. Gross before fees.'
  >

Oztix records by context

Each record lists its RecordTable columns with the type of the field behind each one, how it reads, where it goes on a phone (narrow), and which hide first as the table narrows (priority), then how the record appears everywhere else.

Event

A show or session at a venue. The record most panes start from.

Order

One purchase by one customer, holding one or more tickets.

Attendee

One ticket and the person holding it. One order can hold several.

Customer

A person who has bought from a client, with their contact details and history.

Ticket type

A price and allocation on sale for one event, like General admission or VIP.

Payout

A payment to a client for one settlement period, covering one or more events.

Refund

Money returned against an order, whole or in part.

Promo code

A code that discounts tickets, with a usage limit and a date range.