refactor(web): all banners through the shared banner component — success variant, non-dismissible, extra classes #283

New issue

Closed

opened 2026-08-04 19:24:59 +02:00 by dominik.polakovics · 1 comment

dominik.polakovics commented

2026-08-04 19:24:59 +02:00

Owner

This was generated by AI during triage.

Split out of umbrella #276 (frontend component reuse, follow-up to #275).

A shared ErrorBanner component exists (dismissible; error and notice variants), yet ~20 inline <div class="banner error" role="alert"> copies survive across the app shell, most routes, and the settings sections — plus inline variants with extra classes (afk-strip-paused, clone-error) and an inline banner success (token reveal). The copies exist because the component's API doesn't cover their needs: non-dismissible usage, a success variant, extra-class passthrough.

Extend the banner API to cover the real needs and migrate every inline copy. The agent brief follows in a comment.

> *This was generated by AI during triage.* Split out of umbrella #276 (frontend component reuse, follow-up to #275). A shared `ErrorBanner` component exists (dismissible; `error` and `notice` variants), yet ~20 inline `<div class="banner error" role="alert">` copies survive across the app shell, most routes, and the settings sections — plus inline variants with extra classes (`afk-strip-paused`, `clone-error`) and an inline `banner success` (token reveal). The copies exist because the component's API doesn't cover their needs: non-dismissible usage, a success variant, extra-class passthrough. Extend the banner API to cover the real needs and migrate every inline copy. The agent brief follows in a comment.

dominik.polakovics added the

enhancement

label

2026-08-04 19:24:59 +02:00

dominik.polakovics commented

2026-08-04 19:25:06 +02:00

Author

Owner

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: All banner markup renders through the shared banner component(s); migrate the ~20 inline copies.

Current behavior:
ErrorBanner renders a dismissible banner with error and notice variants, correct roles (alert for error, status otherwise), and text-only message rendering. Alongside it, roughly 20 call sites hand-roll <div class="banner error" role="alert"> — the app shell, most list/detail routes, and the settings sections. Some carry site-specific extra classes (the AFK strip's paused banner, Repos' clone-error banner) and the token-reveal flow hand-rolls a banner success with role="status". The inline copies exist because the component API lacks what those sites need: non-dismissible rendering, a success variant, extra-class passthrough.

Desired behavior:
The shared banner API covers the real needs found in the codebase — non-dismissible usage (no dismiss button rendered when no dismiss handler is meaningful), a success variant, and passthrough of extra classes — and every inline banner copy migrates to it. Role semantics preserved per variant (alert for error, status for notice/success). Message content keeps rendering as text content, never HTML (the v0 sticky-banner property noted in the component). No visual change.

Key interfaces:

ErrorBanner (or a generalized Banner it delegates to) — extended, not forked; existing call sites keep working unmodified or are trivially migrated
The banner CSS classes (error, notice, success, extra modifiers) remain the styling hooks, applied only by the component in production code after migration
A colocated test in the SectionCard style covering variants, role mapping, dismissible vs not

Acceptance criteria:

The banner component supports non-dismissible rendering, a success variant, and extra-class passthrough, with tests
Every production inline class="banner …" construction is migrated to the component (test fixtures excepted)
A repo-wide search for hand-rolled banner markup in production frontend code finds only the component
Each migrated site keeps its exact role attribute, classes, and text as today
No visual change; existing frontend tests pass

Out of scope:

Toast notifications and any new banner styling
Changing which errors are shown where, or dismiss behavior at sites that have it today
The other pattern families tracked by #276

> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** All banner markup renders through the shared banner component(s); migrate the ~20 inline copies. **Current behavior:** `ErrorBanner` renders a dismissible banner with `error` and `notice` variants, correct roles (`alert` for error, `status` otherwise), and text-only message rendering. Alongside it, roughly 20 call sites hand-roll `<div class="banner error" role="alert">` — the app shell, most list/detail routes, and the settings sections. Some carry site-specific extra classes (the AFK strip's paused banner, Repos' clone-error banner) and the token-reveal flow hand-rolls a `banner success` with `role="status"`. The inline copies exist because the component API lacks what those sites need: non-dismissible rendering, a success variant, extra-class passthrough. **Desired behavior:** The shared banner API covers the real needs found in the codebase — non-dismissible usage (no dismiss button rendered when no dismiss handler is meaningful), a success variant, and passthrough of extra classes — and every inline banner copy migrates to it. Role semantics preserved per variant (`alert` for error, `status` for notice/success). Message content keeps rendering as text content, never HTML (the v0 sticky-banner property noted in the component). No visual change. **Key interfaces:** - `ErrorBanner` (or a generalized `Banner` it delegates to) — extended, not forked; existing call sites keep working unmodified or are trivially migrated - The `banner` CSS classes (`error`, `notice`, `success`, extra modifiers) remain the styling hooks, applied only by the component in production code after migration - A colocated test in the `SectionCard` style covering variants, role mapping, dismissible vs not **Acceptance criteria:** - [ ] The banner component supports non-dismissible rendering, a success variant, and extra-class passthrough, with tests - [ ] Every production inline `class="banner …"` construction is migrated to the component (test fixtures excepted) - [ ] A repo-wide search for hand-rolled banner markup in production frontend code finds only the component - [ ] Each migrated site keeps its exact role attribute, classes, and text as today - [ ] No visual change; existing frontend tests pass **Out of scope:** - Toast notifications and any new banner styling - Changing which errors are shown where, or dismiss behavior at sites that have it today - The other pattern families tracked by #276

dominik.polakovics added the

ready-for-agent

label

2026-08-04 19:25:06 +02:00

dominik.polakovics referenced this issue

2026-08-04 19:25:35 +02:00

Frontend component reuse: inventory repeated UI patterns, then file per-family extraction issues #276

dominik.polakovics referenced this issue

2026-08-04 19:25:35 +02:00

Frontend component reuse: inventory repeated UI patterns, then file per-family extraction issues #276

dominik.polakovics referenced this issue from a commit

2026-08-04 21:23:32 +02:00