| Filename | Latest commit message | Latest commit date |
|---|---|---|
601068f1eb
Three more asks from the same review thread: - "agentspage is now giant and deserves a split" - AgentsPage.tsx was 1047 lines. Split into AgentTypes.ts (AgentRow and friends), WantedMenu.tsx, AgentCard.tsx (+ its own CSS), leaving AgentsPage.tsx as state/actions/columns/the render tree - 649 lines, and every piece it composes is now independently readable. - "what about the component that represents filtered data ... that the card view and table can both use?" - extracted FilterableView (ui/filterable-view/): takes columns/rows/rowKey/storageKey/view/ renderCard, builds its filter bar from *every* filterable column (not a hand-picked subset - the old AgentFilterBar only showed 4 of the agent columns' 6 filterable fields, an accidental gap the table's own popovers didn't have), and renders either the card list or Table. AgentsPage now just tells it which view to show; the view toggle itself stays page-side since it's Panel-header chrome, not filtering. Disclosed side effect: card view's filter bar now also covers message/config-PR (text filters), matching table view exactly instead of a narrower subset. - CSS audit: AgentsPage.css now holds only what's genuinely page-specific (the view toggle, the detail-panel field grid) - everything else moved to its owning component's own colocated CSS. FilterableView gets a /components demo (view toggle + filter bar + both render modes, same day per the design guide). Verified: AgentsPage still renders the same (real screenshot), and the demo's own table toggle produces a real Table with the same rows. |
||
| .. | ||
| packages | ||
| .gitignore | ||
| npm-deps-hash | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
hyperhive frontend
npm workspaces project for the hyperhive browser-facing assets:
packages/shared/— shared modules used by both surfaces (terminal pane, Catppuccin palette + body typography).packages/dashboard/— the hive-c0re dashboard SPA.packages/agent/— the per-container web UI (default agent page, stats, screen).
Build
npm install # one-off; uses the checked-in package-lock.json
npm run build # builds every workspace into packages/*/dist/
The Rust binaries serve packages/dashboard/dist/ and
packages/agent/dist/ via tower_http::ServeDir at runtime; the
build derivation is wired up in nix/packages/frontend.nix. Per-agent
additions are layered on top of the default agent dist via the
hyperhive.frontend.extraFiles option in agent.nix.
Why npm + esbuild
- Hermetic: dependencies vendored via the checked-in lockfile;
buildNpmPackagein nix uses it as the source-of-truth so the output is reproducible without network access at build time. - esbuild: vanilla-JS bundler, no framework runtime overhead.
Each workspace's
build.mjsis ~30 lines. - Single-PR migration: see the tracked design proposal and the four-commit shape (npm scaffold → nix derivations → container plumbing → Rust cutover).