fix(theme): 0.3.1 — interactive-render nav backstop (issue #6)
Under an interactive Blazor render mode the runtime replaces the prerendered
<details> after DOMContentLoaded, so nav-state.js (wired on load, re-run only on
'enhancedload') never wires the live rail — no aria sync, no persistence, no
active-reveal — and native <details> content-hiding is unreliable, leaving a
collapsed section's items visible. 0.3.1:
- nav-state.js: add a MutationObserver backstop that re-runs apply() when
details.rail-section nodes are (re)inserted; idempotent via the per-element
init guard, loop-safe (childList-only + active-reveal's !open guard).
- layout.css: explicit .rail-section:not([open]) > .rail-section-body{display:none}
so visual collapse works across all render modes.
- themeissues.md: document issue #6; Directory.Build.props 0.3.0 -> 0.3.1.
48 bUnit tests green.
This commit is contained in:
Joseph Doherty
@@ -20,6 +20,7 @@ All file references below point at the kit source under `src/ZB.MOM.WW.Theme/`.
|
||||
| 3 | Medium | `nav-state.js` | Persistence wires once on `DOMContentLoaded`; not re-applied after Blazor enhanced navigation / dynamic re-render. | ✅ Fixed |
|
||||
| 4 | Low | `NavRailSection` | Always-expanded SSR default causes a flash / layout shift of collapsed sections on load. | 📄 Accepted tradeoff (documented) |
|
||||
| 5 | Low (optional) | `LoginCard` | Heading bakes the localizable `— sign in` suffix into the product title with no separate hook. | ✅ Fixed |
|
||||
| 6 | High | `NavRailSection` / `nav-state.js` | Under **interactive** Blazor render mode the whole collapsible nav is non-functional: clicking a header doesn't hide items, and `nav-state.js` never wires (no aria sync, no persistence, no active-reveal). | ❌ Open (found in 0.3.0) |
|
||||
|
||||
---
|
||||
|
||||
@@ -230,6 +231,92 @@ or add an optional `Heading` parameter that, when set, replaces the default head
|
||||
|
||||
---
|
||||
|
||||
## Issue 6 — Collapsible nav is non-functional under interactive Blazor render mode
|
||||
|
||||
**Severity:** High · **Files:** `Components/NavRailSection.razor`, `wwwroot/js/nav-state.js`,
|
||||
`wwwroot/css/layout.css` · **Status:** Open (found in 0.3.0)
|
||||
|
||||
> **This corrects Issue 3's note**, which claimed interactive Blazor Server consumers are
|
||||
> "largely unaffected because the rail is patched in place." Direct observation of the live
|
||||
> ScadaBridge Central UI (global `@rendermode InteractiveServer`) shows that is **false** —
|
||||
> the kit's `<details>`/JS nav does not work under interactive render modes at all.
|
||||
|
||||
**Symptom.** In an app that renders the rail under an interactive render mode
|
||||
(`InteractiveServer`, `InteractiveWebAssembly`, or `InteractiveAuto`), the collapsible nav is
|
||||
visually and functionally dead:
|
||||
|
||||
1. Clicking a section header toggles the chevron (▶/▼) but **does not hide the section's
|
||||
items** — the links stay fully visible under a "collapsed" chevron.
|
||||
2. `aria-expanded` never changes, `localStorage` is never written, the saved state is not
|
||||
restored on reload, and the active-section auto-reveal (Issue 2) does not fire.
|
||||
|
||||
**Root cause.** The kit nav is a **static-SSR / CSS-only** design (NavRailSection's own
|
||||
comment: *"works in static SSR"*). Under an interactive render mode, Blazor's runtime
|
||||
**owns and re-renders the `<details>`/`<summary>` DOM** after it adopts the prerendered
|
||||
markup. Two independent consequences, both observed live:
|
||||
|
||||
- **Native collapse is defeated.** On the live page a closed section has `details.open === false`
|
||||
and its `::details-content` computes `content-visibility: hidden`, yet the
|
||||
`.rail-section-body` and its links remain laid out and visible (measured non-zero height /
|
||||
non-null `offsetParent`). Blazor's management of the native `<details>` desyncs the browser's
|
||||
built-in content-hiding. The body's `display` value (flex/block/grid/inline) makes no
|
||||
difference — only an explicit `display: none` actually hides it.
|
||||
- **`nav-state.js` never wires the live DOM.** The interactive `<details>` elements have **no
|
||||
`data-zbnav-initialized` attribute**, i.e. `wire()` never ran on them: `apply()` runs on
|
||||
`DOMContentLoaded` against the *prerendered* nodes, which Blazor then replaces, and the only
|
||||
re-run hook (`enhancedload`, added for Issue 3) does not fire under interactive render modes.
|
||||
So aria sync, localStorage persistence, and active-reveal are all inert.
|
||||
|
||||
This matters for the kit's stated goal: per the normalization notes, nav-expand persistence was
|
||||
promoted into the kit at 0.2.0 *"so all three apps share one persistence mechanism."* One of the
|
||||
three consumers (ScadaBridge Central UI) is interactive Blazor Server, where that mechanism
|
||||
silently does nothing.
|
||||
|
||||
**Verified evidence (live, global InteractiveServer).** On a logged-in dashboard:
|
||||
`data-zbnav-initialized` absent on every `details.rail-section`; after clicking a header,
|
||||
`details.open === false` but the section's link still reports `clientHeight: 33` and a non-null
|
||||
`offsetParent`; setting `.rail-section-body { display:none }` is the only thing that hides it;
|
||||
`localStorage` has no `zbnav:*` keys before or after toggling.
|
||||
|
||||
**Recommended fix (two parts — both belong in the kit).**
|
||||
|
||||
1. **Make the collapse render-mode-robust (CSS).** Don't rely solely on the native
|
||||
`<details>` content-hiding; hide the body explicitly when closed:
|
||||
|
||||
```css
|
||||
/* layout.css — robust across render modes; native ::details-content hiding
|
||||
is unreliable once an interactive framework manages the <details>. */
|
||||
.rail-section:not([open]) > .rail-section-body { display: none; }
|
||||
```
|
||||
|
||||
(Verified live: this is exactly what hides the items.)
|
||||
|
||||
2. **Make persistence/aria/reveal work under interactive render.** `enhancedload` is
|
||||
static-SSR-only; also wire after the interactive runtime has (re)rendered. Options, in
|
||||
preference order:
|
||||
- Re-run `apply()` from Blazor's post-render hooks — `Blazor.addEventListener('afterStarted', …)`
|
||||
(interactive WASM/Server boot) and re-apply on circuit/render updates; and/or
|
||||
- Add a `MutationObserver` on the rail container that calls `apply()` when
|
||||
`details.rail-section` nodes are added/replaced (framework-agnostic backstop — covers
|
||||
interactive re-renders, enhanced nav, and dynamic nav alike);
|
||||
- **Or** ship an explicitly **interactive** `NavRailSection` variant (a small Blazor
|
||||
component with an `@onclick` toggle and `[Parameter] bool Expanded` two-way state) for
|
||||
consumers that render interactively — which is what NavRailSection's own comment already
|
||||
gestures at (*"Apps that want cookie-persisted expand state keep their own interactive
|
||||
NavSection"*). If the kit's intent is that interactive apps bring their own section
|
||||
component, say so loudly in the docs and have the CSS-only one degrade gracefully (part 1
|
||||
still applies so at least the visual collapse works).
|
||||
|
||||
**Verify.** In an interactive-render host: clicking a header hides the section's items; the
|
||||
summary's `aria-expanded` flips; `localStorage` gets a `zbnav:<key>` entry; the state survives
|
||||
a reload; and deep-linking into a collapsed section reveals it.
|
||||
|
||||
**Consumer note (ScadaBridge).** Until the kit ships this, ScadaBridge's Central UI nav
|
||||
collapse is a no-op; the Playwright `NavCollapseTests` that exercise toggling, persistence, and
|
||||
auto-reveal are therefore testing behavior the app does not currently have.
|
||||
|
||||
---
|
||||
|
||||
## Not kit bugs — expected consumer adaptations
|
||||
|
||||
For the avoidance of doubt, the following are **not** theme issues; they are the normal cost
|
||||
|
||||
Reference in New Issue
Block a user