Module table 

A column-oriented table over caller-owned rows.

The table sorts nothing and selects nothing. A click on a sortable header reports the key and the direction that click implies; the table then renders exactly the order and the sort indicator the caller passes back, so a host that refuses to re-sort keeps the order that still holds.

Which cells publish

Every rendered row publishes a Role::Row node. Cells do not: a table of two hundred rows and six columns would bury every other assertion target in twelve hundred nodes that say nothing a row does not already say. A cell publishes a Role::Cell node only where the caller marks it with Cell::published, and its id is <row id>.<column key>.

Materialized rows are not virtualized; a row source is

Table::rows takes materialized rows, so the caller has already built every cell element by the time the table sees them, and an element can be laid out once. Virtualization needs a row it can build on demand, and it needs to build it more than once per frame — a uniform_list measures one row to learn the height before it builds the range it shows. A vector cannot answer that twice. So the materialized body renders every row it is given, under a header that stays put while the body scrolls.

Table::rows_from is the way in for a collection larger than the viewport: a count and a closure, the same shape crate::data::List takes. A table built that way lays out only the rows Table::visible_rows admits, and asks the caller for those and no others. It is offered alongside Table::rows rather than replacing it, because a table of six settings should not have to be written as a closure over an index.

A table has no keyboard navigation of its own — a click is its only way to report a row — so a caller that moves the selection somewhere the viewport has never drawn brings it into view with crate::data::reveal_row, naming the table’s body as <table ident>.body. A surface that wants the keyboard to walk a collection larger than its viewport wants crate::data::DataGrid, which does that itself.

Table or DataGrid

crate::data::DataGrid is the heavyweight alternative: it takes a render closure instead of rows, so it virtualizes over gpui::uniform_list, and it carries the machinery an administrative surface needs — resizable and reorderable columns, a left-pinned group, three selection modes with a truthful select-all, opened rows with a detail region, and cells that become fields.

Reach for Table for a settings summary, a short run list, a preview of a result set — anything a reader takes in at a glance. Reach for DataGrid when the data set is larger than the viewport, or when the surface needs any of the above. If a surface would work as either, pick Table: it is smaller, and a grid’s machinery costs something even when nothing uses it.

Structs

Cell

One cell’s content, and whether it is an assertion target.

Column

One column. key addresses the cells that belong to it and appears in every id the column publishes.

Row

One row, keyed by the identity the row already has.

Table

A table with a header that stays put while the body scrolls.

Enums

Align

Where a cell’s content sits inside its column.

ColumnWidth

How wide a column is: a fixed measure, or a share of what is left over.

SortDirection

Which way a sorted column runs. The table reports a direction and renders whatever order it is handed; it never sorts the rows itself.