A flexible, virtualized data table

The gap

UIKit ships no table. Apps that need one build their own, and they are now building them separately.

A consuming app recently wrote a small one (~60 lines) because it owes several table-driven screens. It is deliberately minimal and shaped for those screens, so it is not a candidate for extraction. But it is the second component that app has had to write for want of a kit equivalent — the first was the breadcrumb, now shipped in 3.10.0 — and a table is the one most likely to be reinvented badly and repeatedly.

What would make it worth using

A table is where a component library earns its keep, because the hard parts are the ones each app gets wrong on its own:

• Column definitions as data, so a screen declares its columns rather than hand-writing markup per table — including how each cell renders, which is where other components (a badge, an address display, an overflow menu) get composed in.
• Alignment and formatting per column, particularly right-aligned numerics. A numeric column that is left-aligned is a readability bug that every table hits once.
• Sorting and an empty state, both of which every consumer needs and none should write twice.
• Accessible semantics by default — real table markup, headers associated with cells, and a caption or accessible name. Worth stating explicitly because virtualized and paginated tables frequently lose this, and the loss is invisible to tests that render into jsdom.

Handling long lists: three strategies, not one

These solve overlapping problems and a table that offers only one will be wrong for half its consumers. All three should be options, and the component should not force a choice:

• Virtualization — render only what is on screen. The right answer for a long list the user scrolls freely. Retrofitting it into a table someone already shipped is painful, which argues for designing it in from the start.
• Pagination — fetch and render a page at a time. The right answer when the data source is paged, when a user needs stable positions to return to, or when a total count is meaningful. Needs to work with both client-held and server-held data, since those differ in who owns the page state.
• Infinite scroll — append as the user reaches the end. Good for feeds and activity logs, poor for anything a user needs to navigate back into, and it interacts badly with virtualization unless designed together.

Virtualization and infinite scroll are commonly wanted at once, and the combination is where naive implementations break. Pagination and virtualization can also coexist for a large page size. Worth treating as composable rather than a single mode enum.

Whatever the shape, keyboard and screen-reader behaviour needs to survive all three — loading more rows should not move focus or silently change what is under the cursor.

Worth deciding early

Whether row selection, expansion, pinned columns and column resizing are in scope, or whether this stays a presentation component that takes prepared data. A table that tries to own state tends to fight the app that embeds it, and a table that owns none pushes the same boilerplate into every consumer. That boundary is the design question, more than the rendering — and it is sharpest for paging, where whoever owns the page also owns the fetch.

Designing against real consumers

Worth checking what UI Builder, RWA Wizard and Role Manager each do today before fixing the API, since a shared table has to satisfy consumers that have not asked for it yet. At least one other app is willing to be an early adopter once something exists.

Review how UI Builder, RWA Wizard, and Role Manager currently implement tables before proposing an API. Define the component boundary and verify that virtualization, pagination, infinite scroll, sorting, empty states, selection or expansion, and accessible table behavior can coexist; done means the design decisions and early-adopter requirements are settled.