📌 Description
Every other state-changing action in the app surfaces a toast via useToast's notify — registering/deactivating an anchor (AnchorsPanel, AnchorDetail), opening/executing/cancelling a settlement (SettlementsPanel, SettlementDetail). WalletProvider's connect() and disconnect() (src/components/WalletProvider.tsx), and ConnectButton (src/components/ConnectButton.tsx) which calls them, do neither — there is no useToast import or notify call anywhere in either file. Connecting or disconnecting the wallet only changes the header button's label, with no confirmation toast telling the user the action succeeded, unlike every other mutating action in the app which pairs a state change with an explicit, consistent success notification.
🧩 Requirements and context
- Connecting and disconnecting the wallet should notify the user via the existing toast system (e.g.
notify("success", "Wallet connected.") / notify("success", "Wallet disconnected.")), consistent with how every other mutating action in the app confirms itself.
- The existing button-label change and the disconnect confirmation dialog must be unchanged.
- Cross-tab sync (the
storage event handler in WalletProvider) should not trigger a toast in the tab that didn't initiate the change, to avoid a confusing notification for an action the current tab's user didn't take.
🛠️ Suggested execution
- Since
WalletProvider/ConnectButton sit outside ToastProvider's typical consumer pattern only by omission (ToastProvider already wraps the whole tree in layout.tsx), add a useToast() call in ConnectButton (which already renders within the provider tree) and call notify("success", ...) after a successful connect()/disconnect() call, rather than inside WalletProvider itself (keeping the toast-triggering storage-sync distinction simple).
- Extend
src/components/ConnectButton.test.tsx with a test asserting a toast/notification appears after connecting and after confirming a disconnect.
✅ Acceptance criteria
🔒 Security notes
No new attack surface; a client-side UX consistency enhancement using the app's existing notification system.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
Every other state-changing action in the app surfaces a toast via
useToast'snotify— registering/deactivating an anchor (AnchorsPanel,AnchorDetail), opening/executing/cancelling a settlement (SettlementsPanel,SettlementDetail).WalletProvider'sconnect()anddisconnect()(src/components/WalletProvider.tsx), andConnectButton(src/components/ConnectButton.tsx) which calls them, do neither — there is nouseToastimport ornotifycall anywhere in either file. Connecting or disconnecting the wallet only changes the header button's label, with no confirmation toast telling the user the action succeeded, unlike every other mutating action in the app which pairs a state change with an explicit, consistent success notification.🧩 Requirements and context
notify("success", "Wallet connected.")/notify("success", "Wallet disconnected.")), consistent with how every other mutating action in the app confirms itself.storageevent handler inWalletProvider) should not trigger a toast in the tab that didn't initiate the change, to avoid a confusing notification for an action the current tab's user didn't take.🛠️ Suggested execution
WalletProvider/ConnectButtonsit outsideToastProvider's typical consumer pattern only by omission (ToastProvideralready wraps the whole tree inlayout.tsx), add auseToast()call inConnectButton(which already renders within the provider tree) and callnotify("success", ...)after a successfulconnect()/disconnect()call, rather than insideWalletProvideritself (keeping the toast-triggering storage-sync distinction simple).src/components/ConnectButton.test.tsxwith a test asserting a toast/notification appears after connecting and after confirming a disconnect.✅ Acceptance criteria
🔒 Security notes
No new attack surface; a client-side UX consistency enhancement using the app's existing notification system.
📋 Guidelines