bugfix/fwf-5828:Fixed delete btn loading issue

[fahad-aot]

User description

📝 Pull Request Summary

Description:
Fixed delete burron loading issue

Related Jira Ticket:
https://aottech.atlassian.net/browse/FWF-5828

DEPENDENCY PR:

Type of Change:

• ✨ Feature
• 🐞 Bug Fix
• ♻️ Refactor
• 🧹 Code Cleanup
• 🧪 Test Addition / Update
• 🔄 SYNC PR (for syncing different repos)
• 📦 Dependency / Package Updates
• 📘 Documentation Update
• 🚀 Deployment / Config Change / Yaml changes

---

💻 Frontend Changes

Modules/Components Affected:

Summary of Frontend Changes:

UI/UX Review:

• Required
• Not Applicable

Screenshots / Screen Recordings (if applicable):

---

⚙️ Backend Changes (Java / Python)

Modules/Endpoints Affected:

Summary of Backend Changes:

API Testing:

• Done
• Not Applicable

Screenshots / Screen Recordings (if applicable):

✅ Checklist

• Code builds successfully without lint or type errors
• Unit tests added or updated [Backend]
• UI verified [Frontend]
• Documentation updated (README / Confluence / API Docs)
• No sensitive information (keys, passwords, secrets) committed
• I have updated the CHANGELOG with relevant details
• I have given a clear and meaningful PR title and description as per standard format
• I have verified cross-repo dependencies (if any)
• I have confirmed backward compatibility with previous releases

Details:

---

👥 Reviewer Notes

---

PR Type

Bug fix

---

Description

• Stop deletion spinner after completion

• Reset deletion loading state on close

• Align deletion modal state updates

---

Diagram Walkthrough

flowchart LR
  DeleteAction["Delete action initiated"] --> API["Delete API call"]
  API --> Success["On success handler"]
  Success -- "dispatch setFormDeleteStatus" --> ModalClosed["Modal closed"]
  Success -- "setIsDeletionLoading(false)" --> SpinnerStopped["Loading spinner stopped"]

Loading

File Walkthrough

Relevant files

Bug fix

FormTable.js Reset deletion loading state after form removal                    forms-flow-web/src/components/Form/constants/FormTable.js After delete flow, stop loading spinner. Ensure loading state resets when closing modal. +1/-0      FormEdit.js Stop deletion spinner after delete status update                  forms-flow-web/src/routes/Design/Forms/FormEdit.js Clear deletion loading flag after status dispatch. Prevent persistent spinner post delete completion. +1/-0

---

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review State Cleanup Order Consider calling setIsDeletionLoading(false) before handleCloseDelete() to avoid any race conditions where the modal unmounts before the loading state is reset, which could trigger setState on an unmounted component. handleCloseDelete(); setIsDeletionLoading(false); }; Duplicate Logic Consistency The same setIsDeletionLoading(false) fix appears in multiple places; ensure all deletion flows (including error/early-return paths) consistently reset loading to prevent stuck spinners. dispatch( setFormDeleteStatus({ modalOpen: false, formId: "", formName: "" }) ); setIsDeletionLoading(false); };

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Use finally to reset loading Ensure setIsDeletionLoading(false) executes even if preceding operations throw by placing it in a finally block. This prevents the delete button from remaining stuck in a loading state on errors. forms-flow-web/src/routes/Design/Forms/FormEdit.js [2308-2312] - dispatch( - setFormDeleteStatus({ modalOpen: false, formId: "", formName: "" }) - ); - setIsDeletionLoading(false); - }; + try { + dispatch( + setFormDeleteStatus({ modalOpen: false, formId: "", formName: "" }) + ); + } finally { + setIsDeletionLoading(false); + } Suggestion importance[1-10]: 7 __ Why: Moving setIsDeletionLoading(false) into a finally block is a sound improvement to ensure the loading state resets on errors, aligning with robustness goals. The change is localized and accurate to the shown code, though it's a defensive enhancement rather than a critical bug fix.	Medium
	Correct loading state handling Move setIsDeletionLoading(false) inside the same success branch and ensure it runs in both success and failure paths. As written, it runs even when deletion fails, hiding the loading state prematurely. Add a failure handler to also reset loading and not show success toast on failure. forms-flow-web/src/components/Form/constants/FormTable.js [99-107] - if (mapperId) { - dispatch(unPublishForm(mapperId)); + try { + if (isDeletionSuccess) { + if (mapperId) { + dispatch(unPublishForm(mapperId)); + } + dispatch(setFormDeleteStatus({ modalOpen: false, formId: "", formName: "" })); + toast.success(t("Form deleted successfully")); + } + } finally { + handleCloseDelete(); + setIsDeletionLoading(false); } - dispatch(setFormDeleteStatus({ modalOpen: false, formId: "", formName: "" })); - toast.success(t("Form deleted successfully")); - } - handleCloseDelete(); - setIsDeletionLoading(false); - }; Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that setIsDeletionLoading(false) should be reliably executed and proposes a finally pattern to avoid premature success signaling, improving UX. However, it introduces an undefined isDeletionSuccess flag and restructures control flow without clear context, reducing accuracy.	Low

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud