[nu-demo] hero_books_ui navbar disappears when clicking into a library — emits /hero_books_ui/library/X (underscore) instead of /hero_books/ui/library/X (slash) #2

New issue

Open

opened 2026-04-28 12:15:16 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-04-28 12:15:16 +00:00

Owner

Symptom

Landing on /hero_books/ui/ (served via hero_router from hero_books/ui.sock) shows the Knowledge World page with a top navbar: Hero Books | Libraries | Tools | Docs + theme toggle. Clicking any library card takes you to a page with Connecting... status but no navbar — the whole header chrome is gone.

Browser URL bar shows: herodemo.gent01.grid.tf/hero_books_ui/library/hero (underscore between hero_books and ui).

Root cause (hypothesis)

hero_books_ui's Askama templates or handler code emit absolute library URLs using the OLD hero_zero / hero_proxy URL shape (/hero_books_ui/library/{name} — with underscore, single path segment) rather than the hero_router shape (/hero_books/ui/library/{name} — with slash between service-name and socket-kind).

hero_router's path routing treats /hero_books/ui/... as "route to hero_books service's ui.sock at path /...". The underscore form /hero_books_ui/... may end up routed to a fallback handler that serves the library page WITHOUT the parent layout/navbar, because the template inheritance / base_path was broken.

Where to look

In hero_books_ui/src/handlers.rs or the templates under crates/hero_books_ui/templates/:

handler_library / handler_library_redirect — any format!("/hero_books_ui/library/{}", ns) or similar hardcoded URL construction.
handler_index — the Knowledge World page — may use one URL form; library pages may use a different one.
The base_path middleware reads X-Forwarded-Prefix — is it being correctly read when the iframe is nested inside hero_os_app?

Hypothesis: handler_index uses the correct base_path (because it's the iframe's root) but handler_library falls through a default that emits the hero_proxy-style URL.

Fix direction

Audit every format!("/hero_books...") in hero_books_ui — replace with {base_path}/... where base_path comes from the X-Forwarded-Prefix extension.
Alternatively: only emit RELATIVE URLs in templates (<a href="library/hero"> instead of <a href="/hero_books_ui/library/hero">) — browser resolves relative to the current iframe URL.
Ensure base.html's template-inheritance block applies to library pages too — check if library.html extends base.html or is standalone.

Demo workaround

None applied — navbar still disappears on library-click. User can go back via browser back button. Demo still shows the beautiful Knowledge World landing page.

home#157 — Books island double-slash URL (sibling — both are URL-generation gaps in hero_books/hero_archipelagos)
home#160 — consolidated demo state
home#171 — dock islands web-feature gaps (companion class)

Signed-off-by: mik-tf

Previous comments from home#176

mik-tf — 2026-04-25T03:31:30Z

Investigation note 2026-04-25

The deployed WASM on herodemo (hash dxhebbe3c50ed1b24ea) was built with the iframe-based Books archipelago variant (hero_archipelagos commit 723d463) — which renders hero_books_ui (Askama) inside an iframe. That variant is what exhibits the navbar-disappear-on-library-click symptom this issue describes.

hero_archipelagos/archipelagos/embed/books/ on development has been migrated to native Dioxus WASM (HomeView, LibraryView, etc. — no iframe). The WASM-native path renders the navbar (or whatever shell is shared) within Dioxus and doesn't have this bug class.

Two paths to closing:

Rebuild WASM with current hero_archipelagos (commit > 723d463), enable island-books-native feature in hero_os_app's web feature list. Native WASM books, no navbar issue, no iframe at all. Bigger lift but the proper devops vision.
Fix hero_books_ui's library.html template to ensure the navbar partial is included. Smaller change but only useful for the legacy iframe path.

Recommending #1 since hero_archipelagos already did the work upstream. This would also fix home#184 (light-mode contrast) since the WASM-native cards inherit hero_os theme tokens directly.

Investigation done; no PR opened — the right fix is a build-config change (island-books-native feature flag) plus WASM rebuild, not a code patch.

Signed-off-by: mik-tf

Originally filed as home#176 on 2026-04-24 by mik-tf — moved to hero_demo as part of consolidating issue tracking.

## Symptom Landing on `/hero_books/ui/` (served via hero_router from `hero_books/ui.sock`) shows the Knowledge World page with a top navbar: `Hero Books | Libraries | Tools | Docs` + theme toggle. Clicking any library card takes you to a page with `Connecting...` status but **no navbar** — the whole header chrome is gone. Browser URL bar shows: `herodemo.gent01.grid.tf/hero_books_ui/library/hero` (underscore between hero_books and ui). ## Root cause (hypothesis) hero_books_ui's Askama templates or handler code emit absolute library URLs using the OLD hero_zero / hero_proxy URL shape (`/hero_books_ui/library/{name}` — with underscore, single path segment) rather than the hero_router shape (`/hero_books/ui/library/{name}` — with slash between service-name and socket-kind). hero_router's path routing treats `/hero_books/ui/...` as "route to hero_books service's ui.sock at path /...". The underscore form `/hero_books_ui/...` may end up routed to a fallback handler that serves the library page WITHOUT the parent layout/navbar, because the template inheritance / base_path was broken. ## Where to look In `hero_books_ui/src/handlers.rs` or the templates under `crates/hero_books_ui/templates/`: - `handler_library` / `handler_library_redirect` — any `format!("/hero_books_ui/library/{}", ns)` or similar hardcoded URL construction. - `handler_index` — the Knowledge World page — may use one URL form; library pages may use a different one. - The `base_path` middleware reads `X-Forwarded-Prefix` — is it being correctly read when the iframe is nested inside hero_os_app? Hypothesis: handler_index uses the correct `base_path` (because it's the iframe's root) but handler_library falls through a default that emits the hero_proxy-style URL. ## Fix direction 1. Audit every `format!("/hero_books...")` in hero_books_ui — replace with `{base_path}/...` where base_path comes from the X-Forwarded-Prefix extension. 2. Alternatively: only emit RELATIVE URLs in templates (`<a href="library/hero">` instead of `<a href="/hero_books_ui/library/hero">`) — browser resolves relative to the current iframe URL. 3. Ensure base.html's template-inheritance block applies to library pages too — check if `library.html` extends `base.html` or is standalone. ## Demo workaround None applied — navbar still disappears on library-click. User can go back via browser back button. Demo still shows the beautiful Knowledge World landing page. ## Related - [home#157](https://forge.ourworld.tf/lhumina_code/home/issues/157) — Books island double-slash URL (sibling — both are URL-generation gaps in hero_books/hero_archipelagos) - [home#160](https://forge.ourworld.tf/lhumina_code/home/issues/160) — consolidated demo state - [home#171](https://forge.ourworld.tf/lhumina_code/home/issues/171) — dock islands web-feature gaps (companion class) Signed-off-by: mik-tf --- ### Previous comments from home#176 #### mik-tf — 2026-04-25T03:31:30Z ## Investigation note 2026-04-25 The deployed WASM on herodemo (hash `dxhebbe3c50ed1b24ea`) was built with the iframe-based Books archipelago variant (`hero_archipelagos` commit 723d463) — which renders `hero_books_ui` (Askama) inside an iframe. That variant is what exhibits the navbar-disappear-on-library-click symptom this issue describes. `hero_archipelagos/archipelagos/embed/books/` on `development` has been **migrated to native Dioxus WASM** (HomeView, LibraryView, etc. — no iframe). The WASM-native path renders the navbar (or whatever shell is shared) within Dioxus and doesn't have this bug class. Two paths to closing: 1. **Rebuild WASM with current hero_archipelagos** (commit > 723d463), enable `island-books-native` feature in hero_os_app's `web` feature list. Native WASM books, no navbar issue, no iframe at all. Bigger lift but the proper devops vision. 2. **Fix hero_books_ui's library.html template** to ensure the navbar partial is included. Smaller change but only useful for the legacy iframe path. Recommending #1 since hero_archipelagos already did the work upstream. This would also fix [home#184](https://forge.ourworld.tf/lhumina_code/home/issues/184) (light-mode contrast) since the WASM-native cards inherit hero_os theme tokens directly. Investigation done; no PR opened — the right fix is a build-config change (`island-books-native` feature flag) plus WASM rebuild, not a code patch. Signed-off-by: mik-tf --- *Originally filed as [home#176](https://forge.ourworld.tf/lhumina_code/home/issues/176) on 2026-04-24 by mik-tf — moved to hero_demo as part of consolidating issue tracking.*