multi-page-v2

multi-page-v2

A multi-page godom app demonstrating Phase B features end-to-end. Four tool islands (counter, clock, simulated system monitor, 3D solar system) each live in their own Go package with colocated HTML; a fifth inline-HTML tool (digiclock) shows up as live prose on the dashboard.

Run

GODOM_NO_AUTH=1 go run ./examples/multi-page-v2/

With DEV mode (reads shared/*.html via os.DirFS at runtime — edit and refresh without rebuild):

GODOM_DEV=1 GODOM_NO_AUTH=1 go run ./examples/multi-page-v2/

Run from the repo root so os.DirFS("examples/multi-page-v2") resolves correctly.

Routes

What each piece demonstrates

Layout

examples/multi-page-v2/
├── main.go                  engine wiring, routes, DEV-mode switch
├── pages/                   Go html/template page chrome
│   ├── layout/base.html     nav + outer shell, included by every page
│   └── {dashboard,counter,clock,monitor,solar}/page.html
├── partials/                shared godom partials (UsePartials target)
│   └── info-note.html       callout with <g-slot/>
├── shared/                  engine's SetFS content
│   └── welcome.html         dashboard banner template
└── tools/                   one Go package per tool
    ├── counter/counter.go + ui/counter.html + ui/{decrement,increment}-button.html
    ├── clock/clock.go + clock.html
    ├── monitor/monitor.go + monitor.html
    ├── solar/solar.go + solar.html + canvas-bridge.js + engine.go + bodies.go + vec3.go
    └── digiclock/digiclock.go   (no HTML — TemplateHTML is inline in Go)

Key design choices

• Tools live in Go packages. Each tool is self-contained — Go code, HTML, plugin JS (solar) all under one folder. Main never references a specific tool's template path; it just calls tool.New(...).
• Main doesn't call SetFS for tool templates. Tools bring their own AssetsFS. SetFS is used here only for the welcome island.
• Page chrome is Go html/template, not godom. Static content (nav, layout) doesn't need godom; the dynamic bits are wrapped in <div g-island="name"></div> targets and godom hydrates them.
• Shared state via embedded pointer. *counter.State lives in main; each island embeds the pointer. When Counter mutates it, godom's shared-pointer refresh auto-refreshes every other island holding the same pointer.

See also

• docs/why-islands.md — why godom calls these "islands" not "components"
• docs/guide.md — getting-started guide
• docs/llm-reference.md — full API reference