Replace Browser Prompts with Accessible Management Forms

[Lakes41]

Difficulty: Advanced

Type: Refactor

Summary

Replace prompt, alert, and confirm usage in management pages with accessible dashboard UI components so pass and member actions are testable, consistent, and user-friendly.

Current Behaviour

The passes page uses prompt() for editing pass names and alert() for mutation errors. The members page uses prompt() for role changes, confirm() for removals, and alert() for mutation errors. These browser dialogs are hard to style, difficult to test reliably, and provide limited accessibility or validation support.

Expected Behaviour

Management actions should use in-app forms, modals, confirmation dialogs, and toast or inline error states. Users should see consistent pending, success, validation, and rollback feedback without relying on blocking browser dialogs.

Suggested Implementation

Create reusable management dialog components for editing pass fields, changing member roles, confirming destructive actions, and displaying mutation errors. Replace direct calls to prompt, alert, and confirm with controlled React state. Ensure keyboard navigation, focus trapping, labels, and error messages are accessible.

Files or Areas Likely Affected

• apps/dashboard/app/passes/page.tsx
• apps/dashboard/app/members/page.tsx
• apps/dashboard/components/
• apps/dashboard/lib/hooks/useOptimisticMutation.ts
• apps/dashboard/test/

Acceptance Criteria

• Pass editing no longer uses prompt().
• Member role changes no longer use prompt().
• Member removal no longer uses confirm().
• Mutation errors no longer rely on alert().
• Dialogs are keyboard-accessible and expose clear labels.
• Tests cover opening, submitting, cancelling, and error states for the new dialogs.

Additional Notes

This should be implemented before adding more complex management flows, since future create/edit actions can reuse the same dialog patterns.

[Franlinozz]

Hi, I’d like to take this issue. I’m comfortable working with React/TypeScript UI refactors and I can handle the accessibility and test coverage required here.

My approach will be to first audit the current management flows in the passes and members dashboard pages and identify every direct prompt(), alert(), and confirm() usage. I’ll then replace them with controlled in-app UI: editable form dialogs for pass names, a role-change dialog for members, confirmation UI for destructive removals, and toast or inline error handling for mutation failures.

I’ll keep the implementation reusable rather than page-specific, likely by adding shared management dialog components and wiring them through React state instead of blocking browser dialogs. I’ll also pay attention to accessibility details like proper labels, keyboard navigation, focus handling, cancel/submit flows, and clear validation/error messages.

Before opening the PR, I’ll add tests covering opening, submitting, cancelling, and error states for the new dialogs, then run lint, tests, and build checks and include the results in the PR description.

[segzydamy]

I’d like to work on this issue.

I have experience building accessible, user-friendly web interfaces and replacing native browser dialogs with modern form-based workflows. For this task, I will:

• Review the existing implementation to identify all browser prompts used for management actions.
• Replace native prompt(), alert(), and confirm() dialogs with accessible, responsive form components that match the application’s design system.
• Ensure the new forms provide proper validation, clear error messages, keyboard navigation, and screen reader support.
• Preserve the existing functionality while improving usability and accessibility.
• Add or update tests to verify the new UI behavior and prevent regressions.

I’ll follow the project’s UI and accessibility guidelines, keep the implementation clean and maintainable, and submit a well-documented pull request with all tests passing.

[leocagli]

Hi — Leo Cagliero here (Starmaker program, currently building on Cosmos LATAM and Open Stellar).

I dug into the two pages. The native dialogs live in exactly four handlers: in apps/dashboard/app/passes/page.tsx, handleEdit calls prompt("Enter new name:") and the mutation's onError calls alert(error.message); in apps/dashboard/app/members/page.tsx, handleChangeRole calls prompt(...), handleRemove calls confirm(...), and both onErrors call alert.

Plan: add a reusable components/Modal.tsx (focus trap, role="dialog" + aria-modal, Esc/overlay close, labelled fields) plus a thin EditFieldDialog/ConfirmDialog, and a useToast for the error path — keeping the existing useOptimisticMutation wiring untouched. Then drive them from controlled state:

const [editTarget, setEditTarget] = useState<string | null>(null);
const handleEdit = (id: string) => setEditTarget(id);
// onError: (error) => toast.error(error.message)  // replaces alert
<EditFieldDialog
  open={!!editTarget} label="Pass name"
  onCancel={() => setEditTarget(null)}
  onSubmit={(name) => { updateMutation.mutate({ id: editTarget!, data: { name } }); setEditTarget(null); }}
/>

Members gets the same EditFieldDialog for role (preserving the [...new Set([...member.roles, role])] merge) and ConfirmDialog for removal. I'll add test/dialog.test.ts covering open/submit/cancel/error using the existing node:test runner.

Could you assign this to me? I can turn the PR around quickly.

[grantfox-oss]

🦊 GrantFox — @segzydamy has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #72)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.