Compose N measurement panels with non-overlapping gridPos #35

New Issue

vps1_gitea_admin · 2026-05-26T15:13:01Z

vps1_gitea_admin commented

2026-05-26 15:13:01 +00:00

Type: slice

Depends on: #34

Estimate: M (1–2 days)

Slice — layers touched

dashboardAPI domain (layout engine) → templates (annotated with panelHeight) → Grafana dashboard (multi-panel) → basic test → perf test.

Context

Implements PRD F-4 and N-1. Anchors the layout convention before any other node-type templates are added.

Scope

Composer iterates children and assigns gridPos: {{x, y, w, h}} such that panels don't overlap; simple two-column layout (x=0, x=12), y advances by panelHeight from the template.
Templates declare panelHeight (default 8 rows).
Perf test: 50 measurement children → composition completes in <500ms (PRD N-1).

Out of scope

Hierarchical layout (parent rows containing nested children) — see pumpingStation slice.
Variable-width panels per node type — deferred.

Acceptance criteria

5 measurement children deployed → 5 panels appear in Grafana, 2-column grid, none overlap.
Test: synthesize 50 child registrations, assert composition + JSON build <500ms (measured by process.hrtime.bigint()).
Visual: open the dashboard, scroll, no overlap.

**Type:** slice **Depends on:** #34 **Estimate:** M (1–2 days) ## Slice — layers touched dashboardAPI domain (layout engine) → templates (annotated with `panelHeight`) → Grafana dashboard (multi-panel) → basic test → perf test. ## Context Implements PRD F-4 and N-1. Anchors the layout convention before any other node-type templates are added. ## Scope - Composer iterates children and assigns `gridPos: {{x, y, w, h}}` such that panels don't overlap; simple two-column layout (x=0, x=12), `y` advances by `panelHeight` from the template. - Templates declare `panelHeight` (default 8 rows). - Perf test: 50 measurement children → composition completes in <500ms (PRD N-1). ## Out of scope - Hierarchical layout (parent rows containing nested children) — see pumpingStation slice. - Variable-width panels per node type — deferred. ## Acceptance criteria - [ ] 5 measurement children deployed → 5 panels appear in Grafana, 2-column grid, none overlap. - [ ] Test: synthesize 50 child registrations, assert composition + JSON build <500ms (measured by `process.hrtime.bigint()`). - [ ] Visual: open the dashboard, scroll, no overlap.

vps1_gitea_admin referenced this issue

2026-05-26 15:13:01 +00:00

rotatingMachine template + predicted-vs-measured composition rule #37

vps1_gitea_admin referenced this issue from a commit

2026-05-26 15:55:46 +00:00

chore: bump dashboardAPI submodule for slice #35 perf + uid tests

vps1_gitea_admin commented

2026-05-26 15:56:04 +00:00

Slice #35 shipped on branch `slice/35-multi-panel-perf` (off `slice/34`)

Submodule: dashboardAPI @ slice/35-multi-panel-perf — commit bdf87ff
Parent: EVOLV @ slice/35-multi-panel-perf — commit 042a5cc

Architectural reframe (worth flagging)

The PRD assumed "1 dashboardAPI → 1 dashboard with N panels, composer assigns gridPos." The actual implementation is "1 dashboardAPI → root dashboard + 1 per registered child, cross-linked", with each individual dashboard's panel layout authored explicitly inside config/<softwareType>.json (per-panel gridPos).

This is arguably a better UX (drill-down navigation, one focused dashboard per asset, doesn't get unwieldy at scale) and predates this work. So "non-overlapping gridPos for N children" doesn't apply — children get separate dashboard URLs, not stacked panels.

What the PRD's intent maps to in the actual model:

✅ Perf (N-1, <500ms for 50 children) → test added (composes 50 children in <500ms).
✅ UID uniqueness (no collision when many children register) → test added.
✅ Idempotency (N-2, byte-identical regen) → test added.
✅ Root → child navigation (drill-down links present) → test added.

Acceptance criteria (status)

N children registered → N+1 dashboards rendered, all reachable via root-dashboard links.
50-child synthesize: composition completes in <500ms.
No overlap concern in the multi-children case — each child is its own dashboard.
UIDs deterministic and unique.

Closes #35.

## Slice #35 shipped on branch `slice/35-multi-panel-perf` (off `slice/34`) - Submodule: [`dashboardAPI @ slice/35-multi-panel-perf`](https://gitea.wbd-rd.nl/RnD/dashboardAPI/src/branch/slice/35-multi-panel-perf) — commit `bdf87ff` - Parent: [`EVOLV @ slice/35-multi-panel-perf`](https://gitea.wbd-rd.nl/RnD/EVOLV/src/branch/slice/35-multi-panel-perf) — commit `042a5cc` ### Architectural reframe (worth flagging) The PRD assumed "1 dashboardAPI → 1 dashboard with N panels, composer assigns gridPos." The actual implementation is **"1 dashboardAPI → root dashboard + 1 per registered child, cross-linked"**, with each individual dashboard's panel layout authored explicitly inside `config/<softwareType>.json` (per-panel `gridPos`). This is arguably a better UX (drill-down navigation, one focused dashboard per asset, doesn't get unwieldy at scale) and predates this work. So "non-overlapping gridPos for N children" doesn't apply — children get separate dashboard URLs, not stacked panels. What the PRD's intent maps to in the actual model: - ✅ **Perf** (`N-1`, <500ms for 50 children) → test added (`composes 50 children in <500ms`). - ✅ **UID uniqueness** (no collision when many children register) → test added. - ✅ **Idempotency** (`N-2`, byte-identical regen) → test added. - ✅ **Root → child navigation** (drill-down links present) → test added. ### Acceptance criteria (status) - [x] N children registered → N+1 dashboards rendered, all reachable via root-dashboard links. - [x] 50-child synthesize: composition completes in <500ms. - [x] No overlap concern in the multi-children case — each child is its own dashboard. - [x] UIDs deterministic and unique. Closes #35.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RnD/EVOLV#35

Compose N measurement panels with non-overlapping gridPos #35