-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(modal): add functionality for identifying which modal triggered the events #2917
Comments
You're right, there's no functionality that can help a user to identify which modal has triggered the event. We need to implement an id of modal or something like that. Btw, a small PR with this fix would be helpful :) |
Any idea when this might be implemented? |
When can this be expected to be released |
Here's my solution. This works well with templated dialogs. It might not work for everyone, but I thought it'd be good to share anyway. Create a separate service. In my example it is "SessionService". Add two public members to it, one being a semaphore counting the number of open open modals (this can be useful to see if stacked dialogs are still open), another an eventEmitter with string payload.
You can apply the same technique to nested dialogs as well. The hosting parent will get events with proper dialog ids. // D P.S. sorry for the garbled up code format - not my fault ;) |
So I'm not supper content with this solution, however here is workaround i have for this issues: let thisModalNumber = this.modalService.getModalsCount();
this.modalService.show(MyDialogComponent);
let sub = this.modalService.onHide.subscribe(() => {
if (thisModalNumber === this.modalService.getModalsCount()) {
if (sub)
sub.unsubscribe();
//
// rest of your code here to process after only this dialog was closed (not a nested child)
//
}
}); |
Why not have the modal service show method return an observable? This would make things a lot less complicated it seems. The modalRef hide method could take an argument that the observable could emit.
The onShow and onHide events really have no business being on the service. The events should come from the modalRef itself. I haven't looked at the source so I don't know if this change would be too big of an undertaking given the current code base but I think it would probably simplify things, not only for the user-facing API, but for the code base itself. |
I've come up with a solution that works for opening modals using the service. This approach could probably be used just as easily for template modals as well. Basically I created a simple base modal component:
All of the modal components that I create extend this class and pass the modal ref into the super call:
then the caller is able to do this:
Using this approach, you never have to listen to this.modalService.onHide, which will always fire no matter which modal is hidden. In my case I have multiple modals opened with the same modal service and closing any of them fired event handlers for all of them. |
@instantaphex |
…the events emitting the dialogRef on modals onShown and onHidden events. This closes valor-software#2917
Hello guys, any news on this issue? :) |
When we use modal with component, the associated component will be destroyed when you close/hide your popup so we can identify close/hide event using the ondestroy event of the associated component : in your parent component where you initialize the modal you define your modal using observable like that :
the destroySubject is the subject related to the modal component destroy event. The modal component take in params the initialState and the destroySubject that will be linked with the onDestroy like that : `export class CallbackModalComponent implements OnInit, OnDestroy {
}` the observable that initializing you modal will complete when the modal is hided. |
Suppose we have two modals in a component and are subscribed to events available, we are unable to identify from which modal is triggered.
Plunkr: https://embed.plnkr.co/jas1u9F7DchyBeN33hCw/
The text was updated successfully, but these errors were encountered: