moonming commented on issue #3344: URL: https://github.com/apache/apisix-dashboard/issues/3344#issuecomment-4932692229
This was fixed by #3391 (`c8d3466`) and I verified the coverage on current `master` (`9979b31`): every detail page now wires Cancel through `useEditCancelGuard`, which shows an unsaved-changes confirm before discarding. Checked all 12 detail pages individually (routes, services, upstreams, consumers, credentials, ssls, protos, secrets, stream_routes, global_rules, plugin_configs, consumer_groups) — each contains `const handleCancel = useEditCancelGuard(form, () => setReadOnly(true));` — plus the two nested service sub-pages which inherit it by reusing `RouteDetail`/`StreamRouteDetail`. No remaining Cancel path calls `setReadOnly(true)` directly. This can be closed. Two related gaps worth tracking separately (not blockers for this issue): 1. The guard deliberately shows the modal on **every** Cancel — including when nothing was changed — because the current `disabled`-toggling form architecture makes `isDirty` unreliable (documented in `useEditCancelGuard.tsx`'s own comment). Fixing the dirty signal would remove one needless click per clean cancel. 2. Browser-level exits are still unguarded: navigating away via the sidebar, browser Back, or closing the tab with a dirty form discards everything silently (`useBlocker`/`beforeunload` appear nowhere in `src/`). That's the most common real-world data-loss path and deserves its own issue — I'm filing a review-summary issue that includes it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
