Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Design] Unify destructive actions and error states

Offen
  • Stimmt etwas nicht?
#160 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
accessibility, design, frontend

Rechercherichtung

Start with the design audit at /design-audit#surfaces and inspect TerminalAlert consumers in apps/web, plus the document deletion and other destructive dialogs. Review the existing focus, recovery, and announcement behavior before mapping the required states. Done means approved audit specimens, accessibility evidence, migrated consumers, screenshots, and passing bun run types, bun run ci, bun run design-audit:test, and bun test.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

triage/human-response

Base branch: main
Branch: maggie/design-error-and-destructive-states
Depends on: None

Goal

Design a coherent system for destructive actions and inline, recoverable, and terminal errors across Chopin.

Context From Planning

  • The destructive dialog and all error specimens in /design-audit#surfaces currently feel visually crude and inconsistent.
  • Destructive buttons, warnings, validation errors, retryable failures, and terminal failures need related semantics without making every error equally loud.
  • This is a proper design pass requiring human review, not a CSS-only color adjustment.

Current Behavior

Errors are presented through a mix of plain destructive text, TerminalAlert, ad hoc banners, and dialog-local copy. Destructive actions use related colors but do not form a clear severity, placement, or recovery system.

Desired Behavior

Define reusable alert/status and destructive-action patterns with clear severity, readable hierarchy, consistent actions, accessible announcements, and calm visual weight appropriate to the consequence.

Acceptance Criteria

  • The design audit covers inline validation, recoverable error with retry, terminal error, destructive confirmation, destructive failure, and disabled/busy destructive action.
  • Each pattern defines icon, title/body hierarchy, action placement, color role, surface, spacing, and announcement semantics.
  • Errors remain understandable without color alone and meet contrast requirements.
  • Retry, cancel, and destructive confirmation keep their existing behavior and focus management.
  • A shared primitive replaces duplicate presentation while retaining consumer-specific copy and recovery behavior.
  • Maggie approves the audit specimens before production migration.

Verification Commands

  • bun run types
  • bun run ci
  • bun run design-audit:test
  • bun test

Primary Surfaces

  • /design-audit#surfaces
  • TerminalAlert consumers in apps/web
  • Document deletion and other destructive dialogs
  • Research, navigation, and composer failures

Expected PR Checks

  • Repo required checks

Report Requirements

  • State matrix and before/after screenshots
  • Accessibility behavior for alerts and dialogs
  • Production consumers migrated
  • Deferred edge cases

Implementation Notes

  • Preserve the distinction between validation, recoverable, and terminal failures.
  • Preserve persistence-before-publication and existing action semantics; presentation must not acknowledge work early.
  • Build on shared tokens/components rather than bespoke dialog and banner CSS.

Stop Conditions

  • Severity semantics or copy require a product decision.
  • A proposed shared component cannot preserve a consumer's focus or recovery contract.
Vorherrschende Sprache
TypeScript
Sterne
409
Forks
24
Ø Merge
11 Std. 58 Min.
Gemergte PRs (30 T.)
456

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus githubnext/chopin

Alle Issues in githubnext/chopin

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.