Refactor: unify delete and restore issue actions and move conditional logic into typescript file#1360
Conversation
|
Tagging @NorbertLoh @HollaG @wx-03 @IzN432 in case any of you can help with the PR ... |
There was a problem hiding this comment.
Pull Request Overview
This PR refactors the issue actions by moving conditional logic out of the template and unifying delete/restore flows into a single handler, while consolidating pending-action tracking into one structure.
- Moved complex boolean expressions from the HTML template into dedicated TypeScript methods.
- Combined delete and restore logic into
deleteOrRestoreIssuewith a boolean toggle. - Replaced two pending-action maps with a single
issuesPendingActionmap.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| src/app/shared/issue-tables/issue-tables.component.ts | Unified delete/restore methods, moved template logic, consolidated pending flags |
| src/app/shared/issue-tables/issue-tables.component.html | Updated action buttons to use new helper methods |
Comments suppressed due to low confidence (1)
src/app/shared/issue-tables/issue-tables.component.ts:160
- [nitpick] Add JSDoc comments for this method (and other new helper methods) to describe parameters, side effects, and intended behavior, improving maintainability.
deleteOrRestoreIssue(isDeleteAction: boolean, id: number, event: Event, actionUndoable: boolean = true) {
| *ngIf="permissions.isIssueDeletable() && !issuesPendingDeletion[issue.id] && this.isActionVisible(action_buttons.DELETE_ISSUE)" | ||
| (click)="deleteIssue(issue.id, $event); $event.stopPropagation()" | ||
| *ngIf="isActionPerformAllowed(true, issue.id)" | ||
| (click)="deleteOrRestoreIssue(true, issue.id, $event); $event.stopPropagation()" |
There was a problem hiding this comment.
There’s a duplicate stopPropagation() call here and in the component method. Remove the inline $event.stopPropagation() in the template since deleteOrRestoreIssue already handles it.
| (click)="deleteOrRestoreIssue(true, issue.id, $event); $event.stopPropagation()" | |
| (click)="deleteOrRestoreIssue(true, issue.id, $event)" |
There was a problem hiding this comment.
There’s a duplicate
stopPropagation()call here and in the component method. Remove the inline$event.stopPropagation()in the template sincedeleteOrRestoreIssuealready handles it.
Agree with this
| (actionedIssue) => this.handleIssueActionPerformedSuccess(isDeleteAction, id, event, actionUndoable), | ||
| (error) => this.errorHandlingService.handleError(error) | ||
| ); | ||
| event.stopPropagation(); |
There was a problem hiding this comment.
[nitpick] Consider handling event propagation in one place only—either in the template or inside this method—to avoid redundant calls and improve clarity.
| event.stopPropagation(); | |
| // Removed event.stopPropagation() to handle event propagation in the template. |
There was a problem hiding this comment.
[nitpick] Consider handling event propagation in one place only—either in the template or inside this method—to avoid redundant calls and improve clarity.
Maybe the event.stopPropagation() can be removed from the template and kept here instead.
| ) | ||
| .subscribe( | ||
| (removedIssue) => this.handleIssueDeletionSuccess(id, event, actionUndoable), | ||
| (actionedIssue) => this.handleIssueActionPerformedSuccess(isDeleteAction, id, event, actionUndoable), |
There was a problem hiding this comment.
The actionedIssue callback parameter is never used. You can simplify this to () => ... to remove the unused parameter and make the code clearer.
| (actionedIssue) => this.handleIssueActionPerformedSuccess(isDeleteAction, id, event, actionUndoable), | |
| () => this.handleIssueActionPerformedSuccess(isDeleteAction, id, event, actionUndoable), |
There was a problem hiding this comment.
The
actionedIssuecallback parameter is never used. You can simplify this to() => ...to remove the unused parameter and make the code clearer.
Agree with this too
| deleteOrRestoreIssue(isDeleteAction: boolean, id: number, event: Event, actionUndoable: boolean = true) { | ||
| const deletingKeyword = 'Deleting'; | ||
| const undeletingKeyword = 'Undeleting'; | ||
| this.logger.info(`IssueTablesComponent: ${isDeleteAction ? deletingKeyword : undeletingKeyword} Issue ${id}`); | ||
|
|
||
| deleteIssue(id: number, event: Event, actionUndoable: boolean = true) { | ||
| this.logger.info(`IssueTablesComponent: Deleting Issue ${id}`); | ||
| this.issuesPendingAction = { ...this.issuesPendingAction, [id]: true }; | ||
|
|
||
| this.issuesPendingDeletion = { ...this.issuesPendingDeletion, [id]: true }; | ||
| this.issueService | ||
| .deleteIssue(id) | ||
| let observableActionedIssue: Observable<Issue>; | ||
| if (isDeleteAction) { |
There was a problem hiding this comment.
[nitpick] Using a boolean flag to toggle delete vs. restore can be error-prone and less readable. Consider using an enum or separate named methods to make the intent explicit.
There was a problem hiding this comment.
[nitpick] Using a boolean flag to toggle delete vs. restore can be error-prone and less readable. Consider using an enum or separate named methods to make the intent explicit.
While an enum could make the intent more explicit, I think a boolean works well here given that the function is only used in the HTML for delete/restore actions. Using a boolean also makes toggling for undo more straightforward.
wx-03
left a comment
There was a problem hiding this comment.
Good job on refactoring all the boolean statements and combining the deletion and restoration of issues! Overall lgtm, left some comments on which of copilot's suggestions are worth keeping
| deleteOrRestoreIssue(isDeleteAction: boolean, id: number, event: Event, actionUndoable: boolean = true) { | ||
| const deletingKeyword = 'Deleting'; | ||
| const undeletingKeyword = 'Undeleting'; | ||
| this.logger.info(`IssueTablesComponent: ${isDeleteAction ? deletingKeyword : undeletingKeyword} Issue ${id}`); | ||
|
|
||
| deleteIssue(id: number, event: Event, actionUndoable: boolean = true) { | ||
| this.logger.info(`IssueTablesComponent: Deleting Issue ${id}`); | ||
| this.issuesPendingAction = { ...this.issuesPendingAction, [id]: true }; | ||
|
|
||
| this.issuesPendingDeletion = { ...this.issuesPendingDeletion, [id]: true }; | ||
| this.issueService | ||
| .deleteIssue(id) | ||
| let observableActionedIssue: Observable<Issue>; | ||
| if (isDeleteAction) { |
There was a problem hiding this comment.
[nitpick] Using a boolean flag to toggle delete vs. restore can be error-prone and less readable. Consider using an enum or separate named methods to make the intent explicit.
While an enum could make the intent more explicit, I think a boolean works well here given that the function is only used in the HTML for delete/restore actions. Using a boolean also makes toggling for undo more straightforward.
| *ngIf="permissions.isIssueDeletable() && !issuesPendingDeletion[issue.id] && this.isActionVisible(action_buttons.DELETE_ISSUE)" | ||
| (click)="deleteIssue(issue.id, $event); $event.stopPropagation()" | ||
| *ngIf="isActionPerformAllowed(true, issue.id)" | ||
| (click)="deleteOrRestoreIssue(true, issue.id, $event); $event.stopPropagation()" |
There was a problem hiding this comment.
There’s a duplicate
stopPropagation()call here and in the component method. Remove the inline$event.stopPropagation()in the template sincedeleteOrRestoreIssuealready handles it.
Agree with this
| ) | ||
| .subscribe( | ||
| (removedIssue) => this.handleIssueDeletionSuccess(id, event, actionUndoable), | ||
| (actionedIssue) => this.handleIssueActionPerformedSuccess(isDeleteAction, id, event, actionUndoable), |
There was a problem hiding this comment.
The
actionedIssuecallback parameter is never used. You can simplify this to() => ...to remove the unused parameter and make the code clearer.
Agree with this too
| (actionedIssue) => this.handleIssueActionPerformedSuccess(isDeleteAction, id, event, actionUndoable), | ||
| (error) => this.errorHandlingService.handleError(error) | ||
| ); | ||
| event.stopPropagation(); |
There was a problem hiding this comment.
[nitpick] Consider handling event propagation in one place only—either in the template or inside this method—to avoid redundant calls and improve clarity.
Maybe the event.stopPropagation() can be removed from the template and kept here instead.
hi, apologies for the poorly-craft commit message body. I've updated it to follow the convention as much as I could, could you please review it? Thanks! |
LGTM! |
Summary:
Fixes #1315
Changes Made:
issuesPendingDeletionandissuesPendingRestoreinto a singleissuesPendingAction.Proposed Commit Message: