The grid: the view where editing happens

The grid is the default view — rows are records, columns are fields, and the cell under your cursor is editable. The other layouts each earn their place (board, calendar, gallery), but they open records to edit them; the grid is where you type straight into the table.

Editing in place

Click a cell to select it; type, or press Enter, to edit. Double-click does the same. Each field type edits in its own way — a select opens its choices, a checkbox toggles, a date opens a calendar — the details are in each type's own guide, starting at field types.

Around the cell:

• Hovering a row shows an expand button that opens the record panel — the whole record as a form, which is the better place for long text and attachments. On a phone or tablet a single tap on the row opens it instead, and the grid is for reading — see Tabla on a phone.
• The last row is + Add record. Right-clicking a row — long-pressing, on touch — opens its menu; selected rows can be deleted together from the footer, into the 7-day trash.
• Edits land field by field and undo works as you'd hope.

Row height

The row-height button (the small lined icon in the view bar) offers four steps: Short, Medium, Tall, Extra tall. Short keeps every row a single line; the taller steps wrap text to two, three or four lines, and chip-style cells (selects, links) wrap their chips the same way.

The choice is part of the view, so a skim-it view can stay short while a read-the-notes view of the same table stays tall.

Column widths and order

Drag a column's edge to resize it; drag its header to move it. Both are remembered by the view, not the table — two views can size and order the same columns differently. The same order can be edited by dragging rows in the Hide fields list.

A column you don't want on screen goes from the chevron on its own header — Hide field — or from that same list, which is also where it comes back.

The first column is always the table's display field and stays frozen at the left while the rest scroll.

The footer

The bottom bar shows the record count for what the view is looking at — filtered, if the view filters — and holds a clickable summary slot under every column: sum, average, count and the rest, computed over all matching records, not only the loaded ones.

Why it stays quick at 100,000 records

Not by loading the table into your browser. Three mechanisms:

• The work happens in Postgres. Every user table is a real Postgres table, and sort, filter and search run as real SQL on the server. The browser asks a question; it never downloads the table to answer it locally.
• Rows arrive 200 at a time. The grid pulls a 200-row page, then the next as you scroll. Paging is keyset ("seek"), not offset — each page picks up exactly where the last ended, so page 500 costs the server about what page 1 does instead of getting slower with depth. The mechanics, and why offset pagination degrades, are in keyset vs offset pagination.
• The grid draws on a canvas, not as a hundred thousand DOM nodes, so scrolling stays smooth regardless of how many rows exist below.

The practical consequence: there is no "load all records" step, ever. You scroll, it pages; you filter, the server answers with the rows that match.

The questions people ask

Can I jump to row 80,000? Not by row number — keyset paging has no "go to offset N". Sort or filter to bring what you want to the top; that's the operation the server is built to make cheap.

Does the row count include filtered-out records? No. The footer counts what the view's filter matches. The filter panel itself shows both numbers — "31 of 122 records".

Where did the grid go when I grouped it? Grouping keeps the grid's grammar — inline editing included — but folds it into per-group sections with their own footers. See group by.