refactor(web): extract the entity list-row card (title + action + metadata) — TokenCard/CredentialCard/ImportRow #282

New issue

Closed

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

dominik.polakovics commented

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

Owner

This was generated by AI during triage.

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

The entity list-row pattern is hand-rolled at least three times: TokenCard, CredentialCard, and ImportRow each render an article.card with a .card-head (a .card-title span, a spacer, a small danger action button with a busy label) above a .card-sub metadata line, plus duplicated confirm-then-delete wiring.

Extract the row shell into a shared component and migrate the known rows. 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). The entity list-row pattern is hand-rolled at least three times: `TokenCard`, `CredentialCard`, and `ImportRow` each render an `article.card` with a `.card-head` (a `.card-title` span, a spacer, a small danger action button with a busy label) above a `.card-sub` metadata line, plus duplicated confirm-then-delete wiring. Extract the row shell into a shared component and migrate the known rows. The agent brief follows in a comment.

dominik.polakovics added the

enhancement

label

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

dominik.polakovics commented

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

Author

Owner

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Extract the entity list-row card (title + right-aligned action + metadata line) into a shared component and migrate the hand-rolled rows.

Current behavior:
Entity rows in list views are hand-rolled per entity. TokenCard, CredentialCard, and ImportRow each render an article with the card class containing a .card-head row — a .card-title span, an always-present spacer, and a small danger button whose label swaps while busy ("Deleting…") — followed by a muted .card-sub metadata line ("Created …, last used …"). The confirm-then-call-API-then-notify-parent delete wiring is duplicated across them.

Desired behavior:
A shared component (name free — e.g. ListRowCard / EntityRow) owns the row markup: title, optional metadata line, and an actions slot. The three known rows render through it with their current text, confirm prompts, and busy behavior intact. Whether busy/confirm handling stays with each caller or is offered by the component is an implementation decision. No visual change.

Key interfaces:

New shared row component with a colocated test in the SectionCard style
The card-title / card-sub CSS hooks keep working; after migration the row markup for these entities is produced only by the component
Per-entity extra classes (e.g. a token-card-style modifier) must remain attachable

Acceptance criteria:

The shared row component exists with a colocated test
The token, credential, and repo-settings import rows render through it
While exploring, any other row matching the exact shape (card-title head + action + card-sub) is either migrated or listed in the PR description as deliberately left out, with a reason
Confirm prompts, busy labels, and error propagation behave exactly as before at every migrated site
No visual change; existing frontend tests pass

Out of scope:

Section/page head rows with an <h2> — that's the head-row family under #276
Changing any confirm-dialog text or delete semantics
The other pattern families tracked by #276

> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** Extract the entity list-row card (title + right-aligned action + metadata line) into a shared component and migrate the hand-rolled rows. **Current behavior:** Entity rows in list views are hand-rolled per entity. `TokenCard`, `CredentialCard`, and `ImportRow` each render an `article` with the `card` class containing a `.card-head` row — a `.card-title` span, an always-present spacer, and a small danger button whose label swaps while busy ("Deleting…") — followed by a muted `.card-sub` metadata line ("Created …, last used …"). The confirm-then-call-API-then-notify-parent delete wiring is duplicated across them. **Desired behavior:** A shared component (name free — e.g. `ListRowCard` / `EntityRow`) owns the row markup: title, optional metadata line, and an actions slot. The three known rows render through it with their current text, confirm prompts, and busy behavior intact. Whether busy/confirm handling stays with each caller or is offered by the component is an implementation decision. No visual change. **Key interfaces:** - New shared row component with a colocated test in the `SectionCard` style - The `card-title` / `card-sub` CSS hooks keep working; after migration the row markup for these entities is produced only by the component - Per-entity extra classes (e.g. a `token-card`-style modifier) must remain attachable **Acceptance criteria:** - [ ] The shared row component exists with a colocated test - [ ] The token, credential, and repo-settings import rows render through it - [ ] While exploring, any other row matching the exact shape (card-title head + action + card-sub) is either migrated or listed in the PR description as deliberately left out, with a reason - [ ] Confirm prompts, busy labels, and error propagation behave exactly as before at every migrated site - [ ] No visual change; existing frontend tests pass **Out of scope:** - Section/page head rows with an `<h2>` — that's the head-row family under #276 - Changing any confirm-dialog text or delete semantics - The other pattern families tracked by #276

dominik.polakovics added the

ready-for-agent

label

2026-08-04 19:24:59 +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

2026-08-04 20:21:19 +02:00