Data interfaces
Composing data interfaces from primitives
How Table, Data Table, Pagination, Empty, Progress, Skeleton, Resizable, and Scroll Area divide semantic and visual responsibilities in dense interfaces.
By Gummy UI · Published
Keep the data structure visible
Gummy Table provides native table anatomy for captions, headers, bodies, rows, and cells. That structure lets browsers and assistive technology preserve row and column relationships. A dense visual treatment should not replace it with a grid of generic containers simply because the cells need custom material or responsive styling.
Data Table composes table structure with application-level sorting and selection controls. Those behaviors need named buttons, announced state, and a clear relationship with the data. The component can provide UI foundations, while the consuming application remains responsible for the actual dataset, query, permissions, and server behavior.
Make every system state explicit
A data view is more than its populated rows. Loading can use a named busy status with decorative skeleton shapes. Empty state needs a useful heading, explanation, and appropriate next action. Progress needs a label and current value when determinate. Errors and retry behavior belong to the application composition even when shared components provide the visual pieces.
Pagination exposes navigation links and current-page state rather than a row of unlabeled numbers. Selection should remain visible and programmatic, while disabled actions explain their availability through the surrounding product context. These states should be designed together because users move between them during one task.
Choose an overflow strategy
Wide data can scroll, reflow, hide lower-priority columns, or change into a different summary. Gummy Scroll Area and Resizable provide controlled primitives, but they do not choose the information architecture. A scroll viewport needs a keyboard and focus strategy, and a resizable boundary needs usable handles and preserved content access.
At narrow widths, the surrounding page must avoid a second accidental horizontal scrollbar. Headers, filters, pagination, and bulk actions need their own wrapping rules. Testing only an empty or short table will not reveal the pressure created by realistic labels and values.
Separate demonstration from backend claims
The Component Lab uses local sample rows and state to exercise these public sources. It does not imply a hosted data service, customer dashboard, analytics product, or supported backend integration. The public baseline’s database example is separate from the component catalogue and no account system is active.
This boundary keeps the component documentation useful. It can explain semantic tables, selection, loading, pagination, scrolling, and resizing without inventing operational capabilities. Consumers can then connect those pieces to the real data and authorization model of their application.