59 lines
2.5 KiB
Markdown
59 lines
2.5 KiB
Markdown
# Contract: Modal Workflows
|
|
|
|
Version: 1.0
|
|
|
|
## State Machine
|
|
|
|
Every modal has exactly these states:
|
|
|
|
```
|
|
closed → open → submitting → success | error
|
|
↓
|
|
cancel → closed
|
|
```
|
|
|
|
- `open`: form visible, submit enabled.
|
|
- `submitting`: form disabled, spinner on submit button, no double-submit possible.
|
|
- `success`: close modal, show toast, refresh affected data.
|
|
- `error`: stay open, show error message inline, re-enable form.
|
|
- `cancel`: close without changes, no confirmation needed unless form is dirty.
|
|
|
|
## Rules
|
|
|
|
- Destructive actions (delete, archive, bulk remove) require a separate confirmation modal — not
|
|
just a disabled button. Confirmation modal must name the target: "Delete component ABC-123?"
|
|
- Never close a modal automatically on error — keep it open so the user can retry or copy the error.
|
|
- Submit button text must describe the action: "Save", "Delete", "Archive" — not "OK" or "Confirm".
|
|
- Modal title must match the action: "Edit Component", "Delete Asset" — not generic "Modal".
|
|
- Escape key and clicking the backdrop close the modal (unless in `submitting` state).
|
|
|
|
## Validation
|
|
|
|
- Validate on submit server-side. Client-side validation is optional progressive enhancement only.
|
|
- Show field-level errors inline below each field.
|
|
- Show a form-level error summary at the top if multiple fields fail.
|
|
- Error messages must be human-readable and action-oriented: "Serial number is required" — not
|
|
"serial_number: cannot be null".
|
|
|
|
## htmx Pattern (server-rendered modals)
|
|
|
|
```
|
|
POST /api/entity → 200 OK + HX-Trigger: "entitySaved" (success)
|
|
→ 422 Unprocessable + partial HTML (validation error, re-render form)
|
|
→ 500 + error message (server error)
|
|
```
|
|
|
|
- On success: server sends `HX-Trigger` header, JS listener closes modal and refreshes list.
|
|
- On validation error: server re-renders the form partial with inline errors (422).
|
|
- On server error: show generic error toast, log full error server-side.
|
|
- Do not use `200 OK` for validation errors — use `422` so htmx can differentiate.
|
|
|
|
## Multi-Step Modals
|
|
|
|
Use only when the workflow genuinely requires staged input (e.g. import preview → confirm).
|
|
|
|
- Show a step indicator (Step 1 of 3).
|
|
- Back button must restore previous step values.
|
|
- Final confirm step must summarise what will happen before the destructive/irreversible action.
|
|
- Single-step edits must NOT be split into multi-step without good reason.
|