u/Ok_Combination_1892

Symfony shipped a TUI component recently and there is almost nothing built on top of it yet, so I wrote the piece I wanted first: a table that scrolls, sorts and filters.

Rows are plain associative arrays, a Column says which key it reads, and an optional formatter turns the value into what you see. Sorting runs on the raw values with <=>, which is fine until you have '10kb' and '9kb' in the same column, so a column can carry its own comparator. Filtering matches against the displayed text rather than the raw value, so typing 1,234 finds the row holding 1234567 — that one I went back and forth on, and I am still not sure it is the right default.

The part that taught me something: I had 92 tests at full line coverage and none of them caught that the widget never read the height it was given. It returned its configured number of rows whatever the terminal was, so at stty rows 10 it produced 17 lines and pushed its own header off the screen. What caught it was putting the thing in a real command in one of my own projects and resizing the window. Fixed in 0.2.0, along with an opt-in mode where the table takes the height the layout gives it.

Keyboard only for now. Mouse events are not merged into the core component yet, so a click on the header to sort has to wait.

https://github.com/Bosun18/tui-datatable

Worth saying outright: the TUI component is marked experimental upstream, so a minor Symfony release can change the API under both of us. I pin the minor version and watch the Tui label in symfony/symfony.

The thing I would like an opinion on: the cursor stops at the first and last row instead of wrapping, unlike SelectListWidget. In a list wrapping feels right, in a table of a few hundred rows it loses your place — but I have only my own use to go on.

EDIT: building this surfaced two bugs in the component itself — the cursor position left behind by Tui::stop(), and a crash when the terminal reports a zero size. Both are fixed upstream now, in symfony/symfony#65244 and #65245.