allow clrAlertClosedChange to execute before closing the alert

[Derek Wang]

Summary

In the current implementation, Clarity removes the alert DOM immediately upon closing and then triggers _closedChanged after that. This means that any custom callback wrapped by clrAlertClosedChange runs after the DOM changes.

However, when the alert contains a button or other interactive elements with click event registrations, it's advisable to prevent memory leaks by removing event listeners before removing the DOM.

To achieve this, it is suggested to consider moving this._closedChanged.emit(true); before this.multiAlertService.close(isCurrentAlert); in the alert.ts close function. This adjustment would allow developers to locate the DOM element inside the alert and remove event listeners accordingly.

For a more detailed reference, please review the code in the provided GitHub link: ng-clarity/alert.ts.

By making this change, developers will have the opportunity to manage event listeners and prevent potential memory leaks associated with event registrations on interactive elements within the alert.

[Daniel Tsanev]

Hello @wghglory ,

Even if we emit the closedChange before the service one this._closed = true; is assigned even before that and the *ngIf on the alert is pointing to that. Although if you are holding a reference to an element inside the alert -- you can still remove the listeners. If you don't have a reference to the element but you have added listeners and that element is removed from the DOM -- then the listeners will be removed too.

However if there are still issues with that -- then we can look into something like having events before / after the alert is closed.