-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Modal component in CoreComponents closes when clicked outside, may result in data loss #5660
Comments
Data loss could also be caused by the Esc key, or accidentally dismissing the changed form in any other way. I think a key distinction is whether or not there's any unsaved changes in the form. If you click "New Item" and immediately dismiss the modal, nothing is lost. Similarly, clicking "Edit Item" and not changing anything, the modal can be dismissed without data loss. The problem is when the form state is changed from its original state, do you agree? If that's the case, then probably a better solution would consider the form state, instead of being statically baked into the modal markup. What comes to mind are confirmations like "are you sure ... unsaved changes will be lost...", though design-wise a dialog-in-a-dialog is not great UX either, so I don't have a clear proposal here, sorry. |
I agree that the "unsaved changes" warning is a better fit for forms. To get this warning automatically, simply return const handleBeforeUnload = (e) => {
e.preventDefault();
// return true;
e.returnValue = true; // for browser compatibility
};
window.addEventListener("beforeunload", handleBeforeUnload);
// and also: window.removeEventListener("beforeunload", handleBeforeUnload); This can be implemented with a hook, using Ecto's changeset to conditionally set the return value , as documented in this blog post by Patrick Thompson. But the big caveat is that |
Connecting the dots, @mxgrn sent this on the Elixir Forum: https://gist.github.com/mxgrn/cb114e52d2a586aeb36241727ec77ac9 |
Let's list all scenarios: Types of dialog
Data dialogs and data lossData loss happens when the user has entered data in the dialog, and through interacting with the dialog or the browser, the dialog with the data gets removed. Standard dialog interaction:
Browser interaction:
Preventing data lossFor standard dialog interaction: adding modal behaviour, not showing navigable links, etc. With traditional HTML pages, you would listen for the Currently, listening for |
Just thought I would add here as I recently encountered a similar issue, when rendering an Uppy instance via a hook inside a modal. Because the dom elements interacted with were not present when phoenix loaded the component, interacting with it closed the modal and left the Uppy app in an incomplete state. I suspect that this is an implementation detail of phx_click_away. Having implemented these things myself before, they are a pain to get right and I love the fact that Phoenix provides this out of the box, so I understand that they don't meet all use cases. The simple work around was just to add an attribute to the modal component that disables click away behaviour for edge cases where this isn;t wanted. Usually, If I have a complex form, I don't put it in a modal, because one of the best things about reactive UIs is that you don't need to layer things on top of each other. Edit: Point I am making (poorly) is that core components can be changed as needed to satisfy your needs. |
For simple messages, closing the dialog when clicking the backdrop is fine. However, when used with forms, an accidental click can result in data loss. For this reason, dialogs often employ 'modal' behaviour, requiring an explicit action - typically via the Save or Cancel buttons.
The
modal
component can easily be improved by introducing amodal
boolean and using the value in thephx-click-away
attribute:The text was updated successfully, but these errors were encountered: