Declarative Tables

Tables are the workhorse of business software. Every application has them: lists of records, logs of events, grids of items. The work that goes into making a table functional — sortable columns, pagination, row actions, responsive behavior, loading states — is largely the same regardless of what data the table shows. Yet it gets rebuilt from scratch more often than it should.

Declarative tables in Swifty eliminate that repetition.

Declare, Don't Build

A table component takes a column definition and a data source. The column definition specifies what to show and how to show it:

• Which fields appear as columns
• The display label for each column header
• Whether the column is sortable (and the default sort direction)
• The minimum width and whether the column can be hidden
• How values should be formatted (as dates, badges, links, or plain text)

That's the configuration. Everything else — pagination controls, sort state management, loading indicators, empty state messages, responsive column hiding — is handled by the component.

Consistent Behavior Everywhere

Every table on the platform is the same component with different configuration. This means sorting works the same way in every table. Pagination looks the same. Column width constraints behave consistently. Actions appear in the same position. Users learn the table interaction pattern once and apply it everywhere.

This consistency is harder to achieve than it sounds. It requires that the table component be general enough to handle any data and flexible enough to support different column configurations. The work of building it well pays dividends across every table in every application.

Columns Are Not Fields

Column definitions and field definitions are related but distinct. A field definition describes the data model — what type of value is stored, how it's validated, what options it has. A column definition describes a table's presentation of that field — what label to use, whether it's sortable, how wide it should be.

This separation matters because the same field might appear in different tables with different column configurations. An "amount" field might appear with a currency symbol in one table and as a plain number in another. The field definition stays stable; the column configuration adapts to context.

Dynamic Column Sets

Tables support dynamic column sets — users can show and hide columns using a column picker. The configuration defines which columns are available and which are visible by default. Users can adjust their visible columns and the preference persists.

For tables where column flexibility isn't appropriate — where the column set is fixed and curated — the column picker can be disabled. The decision is in the configuration.