Paul Trowbridge
d2e706b483
Answers whether Excel-style column collapse — 2025 collapsed while 2026 stays expanded — can be had from our own code, given that the engine is the one thing @perspective-dev ships as a binary. It can, and the engine needs no change. Under split_rollup_mode 'rollup' the engine already emits the whole column tree in pre-order: grand total, then each branch's subtotal immediately followed by its own leaves. Every number Excel would show is already on the client. What is missing is only the ability to not show some of them, which is a DOM concern. So branchCollapse.js hides the leaves of a collapsed branch from a style listener on the regular-table, shrinks the spanning header cells to the columns still showing under them, and makes the group headers clickable. No fork, no engine change, ~150 lines. Verified on an 8-column grid: collapse 2025 (8 -> 6 cells), also collapse 2026 (-> 3), expand 2025 while 2026 stays collapsed (-> 5), header row and body stay width-aligned throughout, and the state survives a redraw the plugin initiates itself (a sort change). Clicking the real header works, not just the API. Where it stops working, which is the point of the spike: The plugin virtualises the column axis by fetching a CONTIGUOUS [start_col, end_col) window from the view and indexing everything by that x. Hiding cells inside that window does not make it fetch more. On the same pivot with no filter — 101 engine columns, 20 rendered — collapsing 2025 leaves 2 of 21 rendered cells visible and the rest of the viewport empty, because 2026's columns are outside the fetched window and nothing tells the grid to widen it. Scroll right and it looks correct again. So this is not a rendering bug to patch; collapse punches holes in the axis rather than compacting it. It holds while the whole axis fits in one fetched window (~20 columns at 1500px), and degrades past that. Fixing it properly means the visible-index -> engine-index indirection a fork would have to add anyway. Not merged, and not suitable to ship as-is. Kept as the evidence for choosing between forking viewer-datagrid and raising it upstream, where nothing is currently in flight: zero open PRs, no branch, and no issue asking for it, though split_rollup_mode itself landed only in PR #3211 on 2026-08-10. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LoxNi8cFsQLPUSw3obb5NH |
||
|---|---|---|
| .. | ||
| public | ||
| src | ||
| .gitignore | ||
| eslint.config.js | ||
| index.html | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| vite.config.js | ||
React + Vite
This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Currently, two official plugins are available:
- @vitejs/plugin-react uses Oxc
- @vitejs/plugin-react-swc uses SWC
React Compiler
The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see this documentation.
Expanding the ESLint configuration
If you are developing a production application, we recommend using TypeScript with type-aware lint rules enabled. Check out the TS template for information on how to integrate TypeScript and typescript-eslint in your project.