You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #477, which made group comparative against TanStack. group-expand could be too — TanStack v9's free package ships everything needed (rowExpandingFeature, row.toggleExpanded()) — but the blocker is app machinery, not adapter capability:
The pre-window setup in apps/bench/src/bench-app.tsx applies the grouping and then calls waitForGroupedRowModel(), which polls the pretable grid ref for the first group row.
The measured trigger is grid.rowModel.setGroupExpanded(groupId, false) — a pretable engine call.
Making it comparative needs a comparator-generic version of both:
Setup: apply the plan override (already generic), then wait for grouped rendering via the DOM — count rows matching a per-profile group-row selector ([data-tanstack-group-row] exists as of feat(bench): make the group script comparative against TanStack #477; pretable's is [data-pretable-group-row]) instead of polling the engine.
Trigger: an adapter-exposed collapse handle, following the onUpdateApiReady pattern — e.g. onGroupToggleReady(collapseFirstGroup), where the tanstack implementation resolves the first group row in sorted order and calls row.toggleExpanded(false).
Plan arithmetic already holds: the post-collapse resultRowCount (leaves − collapsed group's members + all group rows) matches TanStack's expanded-flat-model semantics, per feat(bench): make the group script comparative against TanStack #477's finding that the two models agree on the expanded count exactly.
Worth carrying over from #477: the collapse must target the sorted-first group (the plan picks its probe row from the second group to dodge focus-reconciliation artifacts — see the comment on the group-expand plan in interaction-plan.ts), and the gate's rejection reason for tanstack should flip from "plumbing" to gone once this lands.
The grouped streaming scripts (group-updates, group-updates-stable-keys) are a separate, larger question — they need the comparator update path composed with grouping, and S5 local-max gates tuned for pretable's engine. Not covered by this issue.
Split out of #477, which made
groupcomparative against TanStack.group-expandcould be too — TanStack v9's free package ships everything needed (rowExpandingFeature,row.toggleExpanded()) — but the blocker is app machinery, not adapter capability:apps/bench/src/bench-app.tsxapplies the grouping and then callswaitForGroupedRowModel(), which polls the pretable grid ref for the first group row.grid.rowModel.setGroupExpanded(groupId, false)— a pretable engine call.Making it comparative needs a comparator-generic version of both:
[data-tanstack-group-row]exists as of feat(bench): make the group script comparative against TanStack #477; pretable's is[data-pretable-group-row]) instead of polling the engine.onUpdateApiReadypattern — e.g.onGroupToggleReady(collapseFirstGroup), where the tanstack implementation resolves the first group row in sorted order and callsrow.toggleExpanded(false).resultRowCount(leaves − collapsed group's members + all group rows) matches TanStack's expanded-flat-model semantics, per feat(bench): make the group script comparative against TanStack #477's finding that the two models agree on the expanded count exactly.Worth carrying over from #477: the collapse must target the sorted-first group (the plan picks its probe row from the second group to dodge focus-reconciliation artifacts — see the comment on the
group-expandplan ininteraction-plan.ts), and the gate's rejection reason for tanstack should flip from "plumbing" to gone once this lands.The grouped streaming scripts (
group-updates,group-updates-stable-keys) are a separate, larger question — they need the comparator update path composed with grouping, and S5 local-max gates tuned for pretable's engine. Not covered by this issue.