NEXT: Overlay System (modals/drawers/toasts)

endigo9740 commented 6 months ago

[!WARNING] This issue is a work in progress.

This will act as a hub to centralize for this information.

Proposal

https://github.com/skeletonlabs/skeleton/discussions/2629

Maintainer Requests

The following requests are coming straight from the Skeleton team. These are highly likely be implemented:

[ ] Merge: https://github.com/skeletonlabs/skeleton/issues/2397
[ ] Merge: https://github.com/skeletonlabs/skeleton/issues/2398
[ ] Provide more documentation security restrictions for global reactive state.
[ ] Consider consolidating on the "Registry" method rather than the "Direct" or canned options.
[ ] Provide more parity between params and component props for custom components
[ ] Async/await functionality for response function execution so the Modal stays open while the response computes.
[ ] Review using the native Popover API
[ ] Review using the native Dialog element (likely as a fallback)
[ ] We need to provide more guidance around form handling within modals

Community Requests

The following requests have come from the community and are under consideration:

Bugs and Issues

Feedback

If you have additional updates or requests for this feature, please do so in the comments section below.

adamdva commented 6 months ago

Please consider including a means to disable the backdrop's click to close feature. The ARIA APG guidelines do allow for this, marking a dialog modal only when both: 1) Application code prevents all users from interacting in any way with content outside of it. 2) Visual styling obscures the content outside of it.

jhechtf commented 2 months ago

Please move Modals away from the singleton pattern.

rChaoz commented 2 months ago

Here's a proposal for implementing modals/drawers/popups/whatever: REPL

While this does still use a "singleton" state under the hood, I'm sure this can be avoided. The idea is that, with snippets, it becomes extremely easy to just pass a snippet to a "openModal" function and it gets rendered. No modal store, no anything. This could then easily be refactored into a <Dialog open={true/false}> ... </Dialog> for ease of use.

endigo9740 commented 2 months ago

Thank you @rChaoz - this is somewhat similar to what I have in mind as well (namely how the state rune is used). I've been quietly working on a mixture of Popups and Modals this week, so I should have more to show for this per next week's regular update. Keep an eye out here or in our Discord #announcements channel for that.

The general idea is we're going to aim for the following:

Still provide a queue-based singleton approach. This will default to the registry approach only, while being optional and opt-in.
We'll also provide styles for the native <dialog> component, or a guidance around styling this yourself, for folks that want modals to be triggers as one-off instances.
Finally, we're investigating the use of Floating UI to handle the overlay display of not just popover elements (menus, tooltips, etc) but also modals/drawers/alerts. Kind of unifying all of these under a single umbrella.

But again, I'll plan to showcase my prototypes in next week's update.

endigo9740 commented 2 months ago

We've provided a more in-depth exploration of our proposal for Skeleton v3 popover and modals here:

Written Post: https://github.com/skeletonlabs/skeleton/discussions/2629
Video Walkthrough: https://youtu.be/AU0Lrs16siA

We encourage feedback about the proposal be confined to the post linked above.

jhechtf commented 1 month ago

Where did we land on not using the registry and just allowing users to simply use the components directly?

endigo9740 commented 1 month ago

Where did we land on not using the registry and just allowing users to simply use the components directly?

I'll likely add a guide for integrating the native <dialog> component as an alternative for that pattern. Then you, as the user, have full control over the state and display locally. It won't be as robust, but it's really the only logical alternative as we're going all-in on the registry for our singleton-based system.

Note that we're using this approach as a temporary solution for our v3 doc search until we get a chance to integrate Floating UI. It should give you a good idea of what's possible: https://skeleton-next-5m3jo1af5-skeleton-labs.vercel.app/

Source (NOTE: this is intermixed with a lot of PageFind search code): https://github.com/skeletonlabs/skeleton/blob/6aa8868e04102f13a936c6c96d2e8981f87c421f/sites/next.skeleton.dev/src/components/docs/Search.svelte

I might also encourage you to review the Popover API. It's now (finally) supported across all browsers after a recent Firefox rollout. Personally I find it more intuitive and friendlier than the Dialog: https://developer.mozilla.org/en-US/docs/Web/API/Popover_API

jhechtf commented 1 month ago

So Skeleton will default to the registry? If so, sad to hear.

skeletonlabs / skeleton