vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
hyperhive/frontend
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
iris 841c697301 frontend: convert themed dialogs to light-DOM custom elements 
Pilot for the components-split proposal (mara wants a look at using
custom elements now that we're recent-Firefox-only). Picked the
themed dialog system as the first candidate: most self-contained of
our existing de-facto reusable components (transient, imperative call
sites, no external render-tree coupling), and shared between the
dashboard and per-agent UI already.

<hive-dialog> replaces the manually-built tc-backdrop/tc-box tree in
openDialog — connectedCallback renders, the keydown listener and
click-outside-to-dismiss are owned by the element instead of a
closure, and the outcome is reported via a hive-dialog-close
CustomEvent rather than a hand-rolled resolve callback threaded
through the DOM tree.

<hive-toast> replaces the toast div themedToast built inline —
connectedCallback starts the auto-dismiss timer,
disconnectedCallback clears it (previously a closure-captured
setTimeout handle with no explicit cleanup on early removal).

Both are light DOM (no shadow root) — styling stays exactly where it
already lived, in modal.css's .tc-* classes, imported globally by
both packages' base stylesheets. This was the deliberate call for a
first pilot: shadow DOM would need every shared stylesheet
re-imported per instance (CSS custom properties pierce shadow
boundaries for theming, but plain class rules like .btn don't), which
is real migration cost. Light DOM validates the pattern (lifecycle
encapsulation, less manual event bookkeeping) without paying that
cost; shadow DOM is a drop-in upgrade to these same two classes if a
later pilot wants real style encapsulation.

Public API unchanged (openDialog/themedConfirm/themedPrompt/
themedToast) — every existing call site across dashboard + agent
keeps working with no changes. Verified with a full frontend build.
2026-07-27 20:17:26 +02:00
..
packages frontend: convert themed dialogs to light-DOM custom elements 2026-07-27 20:17:26 +02:00
.gitignore frontend: add npm workspace scaffold under frontend/ 2026-05-23 14:51:01 +02:00
package-lock.json chore(frontend): update npm dependencies 2026-07-15 23:30:25 +02:00
package.json chore(frontend): update npm dependencies 2026-07-15 23:30:25 +02:00
README.md frontend: add npm workspace scaffold under frontend/ 2026-05-23 14:51:01 +02:00

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/modules/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; buildNpmPackage in 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.mjs is ~30 lines.
  • Single-PR migration: see issue #273 for the design proposal and the four-commit shape (npm scaffold → nix derivations → container plumbing → Rust cutover).