Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Design] Unify destructive actions and error states

Aperta
  • Qualcosa non va?
#160 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
accessibility, design, frontend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
392
Fork
22
Merge medio
1g 7m
PR unite (30g)
203

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di githubnext/chopin

Tutte le issue di githubnext/chopin

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.