Sortable Members Table Block for React

Edit MEMBERS, which is also the original order: the order a third press goes back to. Each column is a small Column constant (its key, its label, the order its first press gives and the words for each order), and gapOf says how two rows compare on a key. Add a column by writing its constant, a case in gapOf, a head with SortHead and a cell in the row. Dates are ISO strings written in UTC and formatted by day, so they read the same on the server and in every visitor's time zone.

A head's first press gives the order that column starts with: names and roles A to Z, status active first, rides and dates highest first. The second press reverses it and the third returns the rows to the order they came in, so the table can always be put back. Rows that compare equal, such as two members last active on the same day, are ordered by name in both directions, so an order never depends on how the browser happens to sort. The result is applied on the press and never while the pointer is over a row, so nothing moves under the cursor.

Everything happens in the page: the sort lives in one useState, sortRows reorders the typed rows and nothing is saved or requested. For a long list, keep nextSort and the heads as they are and send the sort (seen:descending) to your API in the press handler, render the rows it returns, and leave the rest of the table alone. The same state also drives the "Sort by" menu, the aria-sort values and the spoken line, so wiring it once wires all of them.

Yes. It's a native table with a caption, th scope="col" heads and a row header for each member. The sorted head carries aria-sort="ascending" or "descending" and the others say none, so a screen reader announces the order as you move along the heads. Each head holds a real button named by its label, so it takes Tab, Enter and Space with a visible focus ring, and the arrow is decorative. A polite status line, present from the start, says what happened after each press ("Original order, as members joined."). The table region is focusable so it can be scrolled by keyboard if it ever overflows. It is the same native table on every library, so it behaves the same on every target.

Below the medium breakpoint the Role and Rides columns fold into a second line under the member's name ("Mechanic, 164 rides"), the avatar goes and the table keeps Member, Last active and Status, so nothing scrolls sideways. The hidden columns can still be sorted: the "Sort by" menu in the header lists every column in both orders, and it follows the heads, so choosing "Rides, most first" in the menu and pressing the Member head land on the same state.

No. The set of rows never changes, every row keeps the same lines whatever its place, and the status line has its own height, so the frame stays the same size. The rows are rebuilt for each order, so there's no row sliding about. If you add filtering or paging to your own table, keep the frame's height with a fixed region or an unseen copy of the longest state.