Fix/recruiter job delete

[YAXH64]

Pull Request

Description

Replaced the native browser window.confirm() dialog used for job deletion with the application's reusable ConfirmDialog component.

Changes Made

• Removed usage of window.confirm() from RecruiterJobsList.
• Added a themed confirmation modal before deleting a job.
• Displays the selected job title inside the confirmation dialog.
• Requires explicit user confirmation before performing deletion.
• Added loading state during deletion requests.
• Prevented duplicate deletion submissions while a request is in progress.
• Improved error handling by keeping the dialog open when deletion fails, allowing recruiters to retry.
• Preserved existing API calls, toast notifications, and local state updates.

Benefits

• Consistent UI/UX across the application.
• Improved accessibility and keyboard navigation.
• Better support for dark/light themes.
• Eliminates reliance on browser-native dialogs.
• Safer deletion workflow with explicit confirmation.

Related Issue

Fixes #1138

Type of Change

• Bug Fix
• Feature
• Enhancement
• Documentation

Testing

Manual Testing

1. Open Recruiter Dashboard → My Job Listings.

2. Click the Delete button for a job.

3. Verify the confirmation modal appears.

4. Click Cancel and verify the job is not deleted.

5. Reopen the modal and click Delete.

6. Verify the job is removed successfully.

7. Verify the success toast appears.

8. Simulate a failed delete request and verify:

   • Error toast appears.
   • Dialog remains open.
   • User can retry deletion.

9. Verify multiple rapid clicks do not trigger duplicate delete requests.

10. Verify Escape key closes the dialog when not loading.

11. Verify dark mode and light mode styling.

Validation

• No TypeScript errors.
• No build errors.
• Existing delete functionality remains intact.
• Existing toast notifications continue to work.

Screenshots / Video

Before

• Clicking Delete opened a browser-native confirmation dialog (window.confirm()).

After

• Clicking Delete opens a themed confirmation modal integrated with the application's design system.

Attach screenshots or a short screen recording showing:

• Delete modal open
• Cancel flow
• Successful delete flow

Checklist

• Code follows project guidelines
• No new compile/type errors
• Tested manually (include steps above)
• No .env, credentials, or node_modules committed
• Docs updated (not required)
• Screenshot or video attached for every UI change

Summary by CodeRabbit

• New Features

  • Enhanced confirmation dialogs with loading indicators and improved keyboard interaction (Escape key support, automatic focus management).
  • Added confirmation step before advancing candidates in the recruitment process.

• Improvements

  • Job deletion now uses an improved confirmation dialog for better user feedback and control.
  • Refined search parameter handling with whitespace trimming.

[github-actions]

Hi @YAXH64, thanks for contributing to InternHack! 🎉

I have automatically:

• 👤 Assigned this PR to you.
• 🏷️ Applied the gssoc:approved label.

Our workflows will now analyze your changes to classify:

• 📈 PR Difficulty: level:*
• 🧩 PR Type: type:*
• 🌟 PR Quality: quality:*

Tip

Ensure your PR description references the issue it resolves (e.g. Closes #123). This allows the bot to inherit any additional labels from that issue!

Happy coding! 🚀

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 281879c1-a5af-40f1-b476-96ee8f783316

📥 Commits

Reviewing files that changed from the base of the PR and between e15a36c and 8a6ffa5.

📒 Files selected for processing (3)

• client/src/components/ui/ConfirmDialog.tsx
• client/src/module/recruiter/applications/ApplicationsList.tsx
• client/src/module/recruiter/jobs/RecruiterJobsList.tsx

---

📝 Walkthrough

Walkthrough

ConfirmDialog is extended with optional description, variant-based button styling, loading state, and custom children rendering. Escape-key and backdrop interactions are made loading-aware. ApplicationsList and RecruiterJobsList both integrate the enhanced dialog: ApplicationsList gates candidate advancement behind confirmation and refactors React Query data fetching; RecruiterJobsList replaces native confirm with styled dialog for job deletion.

Changes

Confirmation Dialog Flows

Layer / File(s)	Summary
ConfirmDialog component enhancement client/src/components/ui/ConfirmDialog.tsx	Props interface relaxes description to optional and adds confirmVariant ("danger" | "primary"), loading, and children for flexible content. Component now focuses cancel button on open, handles Escape-key dismissal only when not loading, disables buttons during loading, renders children when present (else description), applies variant-based confirm button styling, and shows Loader2 spinner while loading. Backdrop click is prevented during loading.
ApplicationsList advance confirmation workflow client/src/module/recruiter/applications/ApplicationsList.tsx	pendingAdvanceApp state gates advance behind user confirmation. useQuery refactored to return both applications and pagination from a combined response object; search params are trimmed before sending to API. ConfirmDialog renders when advance is pending, shows loading based on advancingIds, and triggers handleAdvance on confirm. Advance button now sets pendingAdvanceApp instead of calling handler directly.
RecruiterJobsList job deletion with ConfirmDialog client/src/module/recruiter/jobs/RecruiterJobsList.tsx	Replaces window.confirm() with ConfirmDialog for job deletion. jobToDelete and isDeleting state track deletion context. New async handleDelete calls API to delete by id, updates local jobs list, shows toast notifications, and clears selection in finally. Dialog body conditionally displays selected job title. Delete button now opens dialog instead of calling previous inline handler.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related issues

• [recruiter] Delete job uses window.confirm instead of styled modal — inconsistent with app theme #1138: Addresses the core issue of replacing native window.confirm with a styled modal for job deletion—this PR implements that solution in RecruiterJobsList via the enhanced ConfirmDialog.

Possibly related PRs

• Sachinchaurasiya360/InternHack#1269: Modifies ApplicationsList's Advance action with per-row in-flight state (advancingIds), which complements this PR's pendingAdvanceApp confirmation gate.
• Sachinchaurasiya360/InternHack#204: Introduces the ConfirmDialog component itself; this PR extends that component's capabilities and integrates it into recruiter flows.
• Sachinchaurasiya360/InternHack#1309: Modifies ApplicationsList's advance/status flow and React Query data derivation, directly related to the query refactoring in this PR.

Suggested labels

type:bug, scope:frontend, quality:clean, level:intermediate

Suggested reviewers

• Sachinchaurasiya360

Poem

🐰 A dialog box hops into place,
No more window.confirm showing its face!
Styled confirmations for advance and delete,
Themed and keyboard-aware—oh, what a treat!
The recruiter flows now skip with delight,
Accessibility shining so bright! ✨

🚥 Pre-merge checks | ✅ 1 | ❌ 4

❌ Failed checks (1 warning, 3 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check	❓ Inconclusive	The title 'Fix/recruiter job delete' is partially related but vague—it references the main area of change without clearly describing the specific solution (replacing window.confirm with ConfirmDialog).	Consider a more descriptive title like 'Replace window.confirm with ConfirmDialog in recruiter job deletion' to better convey the primary change.
Description check	❓ Inconclusive	The description covers objectives, changes, testing, and benefits; however, it lacks screenshots/videos despite the template requiring them for any UI change.	Add screenshots or screen recordings showing the confirmation modal in action (open, cancel flow, successful delete flow) to meet the UI change requirement.
Out of Scope Changes check	❓ Inconclusive	While the primary change is in-scope, enhancements to ConfirmDialog and ApplicationsList appear tangentially related but not directly required by issue #1138.	Clarify whether updates to ConfirmDialog and ApplicationsList are necessary dependencies or should be addressed in separate PRs focused on those specific components.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR successfully addresses issue #1138 by replacing window.confirm() with a styled ConfirmDialog, implementing keyboard support, theming, and accessibility as required.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Sachinchaurasiya360]

Code Review — PR #1409: Fix/recruiter job delete

Hi @YAXH64, the ConfirmDialog-based confirmation flow and the pagination state move into the query result are solid improvements. One coordination note.

---

🟡 Merge conflict: ConfirmDialog.tsx is modified identically in PRs #1405, #1406, #1409, and #1410

All four of these PRs apply the same changes to ConfirmDialog.tsx (loading state, confirmVariant, children prop, Escape key handler). Whichever merges second through fourth will have a conflict on this file.

Action needed: Coordinate with @Xenon010101 (PR #1410) on which PR merges first. The others need to rebase and drop their ConfirmDialog.tsx diff since the base will already have those changes.

---

🟡 setPagination removed from query side-effect — verify no regression

The original code had:

queryFn: async () => {
  ...
  setPagination(res.data.pagination);  // side effect in queryFn
  return res.data.applications;
}

This is moved to:

queryFn: async () => ({
  applications: res.data.applications,
  pagination: res.data.pagination,
})
const pagination = data?.pagination ?? null;

The new approach is cleaner (side effects in queryFn are anti-pattern). Just verify that the pagination value is used correctly downstream — if any code was reading the pagination state during the loading state (before data resolves), it now gets null instead of the previous page's pagination, which is correct behavior.

---

✅ Core fix looks correct

Replacing the direct handleAdvance(app.id) call with setPendingAdvanceApp(app) and requiring explicit confirmation before the destructive action is a correct UX improvement.