[fehmer]

Summary

 // ui/table/DataTable.tsx
-const table = createMemo(() =>
-  createSolidTable({ data: data(), getCoreRowModel: getCoreRowModel(), ... })
-)
+const dataTableFeatures = tableFeatures({
+  rowSortingFeature,
+  rowSelectionFeature,
+  // getVisibleCells() is feature-gated in v9; v8 always provided it
+  columnVisibilityFeature,
+  sortedRowModel: createSortedRowModel(),
+})
+const table = createTable({ features: dataTableFeatures, get data() { return data() }, ... })

v9 makes features a required option: row models, fns and feature flags all live in tableFeatures(), and the instance is a single persistent object whose reactive options feed its store — the v8 create-memo-recreate pattern is gone (table().x() → table.x()). Also: flexRender(def, ctx) → <FlexRender header/cell>, columnHelper<TData>() → columnHelper<DataTableFeatures, TData>(), and the ColumnMeta module augmentation moves to the 3-generic shape <TFeatures, TData, TValue>.

Consumers: leaderboard, account results, friends list, pb tables modal, ape keys, blocked users, pending requests.

Review: all usages re-checked

• Pattern matches v9's own migration guidance (the adapter ships a migrate-v8-to-v9 skill): static features, reactive data and controlled state through getters, onXChange as the external setter. The shared module-level dataTableFeatures is safe — tableFeatures() is an identity helper and the sortedRowModel factory is stateless; each table instantiates and caches its own row model (table._rowModels), so one features object serves all instances.
• Reactivity chain verified in table-core v9: table.options is a Solid-signal-backed store whose property reads call the getters, and row models / header groups / columns are memos whose deps read table.options.* + table.atoms.* — all Solid-tracked, so changing props.data / props.columns re-renders the table without recreating it.
• All 7 consumers pass data from a signal/memo/props and columns from a memo — both tracked through the options getters.
• Sorting per table: leaderboard / ape keys / pb tables are server-ordered (enableSorting: false, no arrows); account results is manual (onSortingChange → manualSorting, re-queries the API); friends + pending requests sort client-side; blocked users keeps v8's default sortability (no column disables it — same in v8).

Evidence

• Reactivity pinned by new tests in DataTable.spec.tsx (5 cases against v9.3.1): rows update when data changes, headers update when columns change, persisted sorting applies from the initial render, manual mode reports the sort without reordering rows, row selection marks the active row. Spec 9/9 (was 4/4). Full suite: 85 files, 1647 tests passed; oxlint --type-aware --type-check clean.
• Before: dev account had no friends / ape keys / blocked users — those tables never rendered with data.
  After: re-verified on the dev server with the seeded account, all with zero console errors:
  • leaderboard: 50 rows + "you" card, no sort arrows (server-ordered)
  • account results: manual sort cycle asc → none; rows re-fetched and reordered on every toggle, aria-sort + resultListSort localStorage updated
  • friends list: 2 rows; client-side sort cycle desc → asc → none reorders rows in place, friendsListSort persists
  • pending requests: 2 rows; ape keys: 2 rows; blocked users: 2 rows; pb tables modal: 3 rows

Merge Danger

Door: two-way — a dependency version bump; revert restores v8 behavior (v8 is unmodified in the wild).

Blast Radius: every data table in the frontend. If a v9 runtime behavior differed, tables would mis-render or fail to update — the 7 pages above cover the main paths; the friends-list client-side sort (the only path not exercised before) is now covered by both the new spec tests and the manual checks.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​tanstack/​solid-table@​8.21.3 ⏵ 9.3.1	+8		+28	+1

View full report

[github-actions]

Continuous integration check(s) failed. Please review the failing check's logs and make the necessary changes.