Feature Request
What is the expected behavior?
When the user is about to close a MdDialog window (via Esc key, clickout or close button), for example an edit dialog, it would be nice to be able to have some method to prevent the window from closing to avoid unsaved changes for example.
What is the use-case or motivation for changing an existing behavior?
Since the MdDialog already listens to Esc key events, clickout and has the close() method that is used in the action buttons, it would be much easier to have a method like _afterClosed_ that is called just before the closing event is going to occur, so we could prevent it from happening just returning true or false in a callback function. This way we don't have to overwrite those event listeners.
We did originally plan on adding a beforeClose hook, but not with the ability to cancel the close. The stance has been that, rather than canceling close, the user can disableClose and take control of closing the dialog via whatever criteria suits their application.
Well, I guess something like that could work too. Do you expect to have this functionally any time soon?
In my opinion beforeClose and disableClose serve two different purposes. Imagine a scenario where you want to prompt a user before discarding the changes (no matter how the cancellation happened); then using beforeClose would allow us to cancel closing the dialog. However, disableClose would completely remove the ability for the user to close the dialog (via cancellation) which is not what is expected.
To pitch in here (from over in https://github.com/angular/material2/issues/5209), I'd also like to have the _value_ of the user choice exposed in an observable before/on close, to get access to it without having to wait for the animation.
(This is somewhat tangential to the beforeClose _method_, but it seems to be tracked collectively here).
Much needed! We have a use-case where we want to save data if the user cancels the dialog (via clicking on backdrop or hitting the Esc key). Where the problem comes in, is if there's a server error, we want to keep the modal up still to display the message.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
In my opinion
beforeCloseanddisableCloseserve two different purposes. Imagine a scenario where you want to prompt a user before discarding the changes (no matter how the cancellation happened); then usingbeforeClosewould allow us to cancel closing the dialog. However,disableClosewould completely remove the ability for the user to close the dialog (via cancellation) which is not what is expected.