[dialog] Notify that the user wants to close the dialog

[manolo]

Closing the dialog in client side when the user presses escape or clicks outside is not a good option for flow since validation should be done in server side.
A nice feature is to leave flags noCloseOnOutsideClick and noCloseOnEsc to false, but send an event e.g user-close-action, then the framework can check whether the dialog can be closed.

[jouni]

Can we make the closing callback based somehow? So that by default the callback always returns true immediately, but with Flow it can send an XHR and return true or false asynchronously? And during the callback period the dialog contents would be made inaccessible to the end user, and perhaps with a loading indicator.

[platosha]

FYI something very similar to a closing callback is already implemented in the overlay as a closing event: https://github.com/vaadin/vaadin-overlay/blob/ba7398fcb810afa9aefdf7828063678c3cdf4544/src/vaadin-overlay.html#L256-L267

[manolo]

@platosha the problem is that flow does not support the feature of preventing events since it happens asynchronously, so that event check would never work in flow
@jouni IIRC, there were some plans in flow to support some mechanism to support methods/properties accepting functions by automatically returning some kind of promises, something like

dialog.setBeforeClosingFunction( () => {
   // do something in server side
  //  return a promise
});

@Legioth could give more details

[Legioth]

@manolo There's no need to add anything like a promise-based async RPC to Flow for this case, even though it could slightly simplify the implementation of this kind of feature.

You can just synchronously prevent the event (or trigger the inaccessible state that @jouni suggested ) in cases when there is a server-side handler that might prevent closing. After this, an XHR should be triggered to actually run the server-side handler. If the handler says that the dialog should be closed, then the response can contain a command to programmatically close the dialog.

[Legioth]

But one central aspect here is that this should still require some custom logic in the Flow integration since it would only be necessary to do anything asynchronously when there is a server-side listener that might want to keep the dialog open.

It would just be bad UX to always do that additional async step since the dialog could be allowed to close immediately if there is no server-side listener that might prevent closing.

[manolo]

Just for background info, this is needed in the case of forms inside dialogs in bakery.
There is a requirement that user can close the dialog on escape/click-outside, that is enabled by setting a flag in client-side element. It works, but the dialog is closed and flow is notified via opened-changed, then if dirty flow re-opens the dialog, which is a bad UX

The easiest solution is what I propose, just firing an event in client side and do nothing with the opened property, it's framework responsibility to listen to the event, check for dirty and close in case.