NEXT: Overlay System (modals/drawers/toasts)

[endigo9740]

Warning

This issue is a work in progress.

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

Proposal

• Skeleton Next - Update 8 - Popovers and Modals #2629

Maintainer Requests

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

• Merge: NEXT: Drawers #2397
• Merge: NEXT: Toasts #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:

• Use "inert" for Modal and Drawer to keep focus contained #1655
• Stack based Modal Navigation #1034
• Code completion in ModalComponent #1813
• Modal should return the focus to the triggering element after close #1865
• Confirm Modal should submit on Enter key pressed #1757
• use Skeleton Modals with Shallow routing #2328 (reply in thread)
• Styling issues with native <dialog> element #2409
• feat: optionally prioritize new toasts #2673
• feat: add generic parameters to Modal interfaces #2644

Bugs and Issues

• https://www.youtube.com/watch?v=yZT9906ZCLU

• Modal rendering inconsistent. Disappearing Modals. #2518
• Firefox: Modal with a single button can't be tabbed in #1591
• Custom modal was created with unknown prop "parent" #2176

Feedback

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

[adamdva]

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]

Please move Modals away from the singleton pattern.

[rChaoz]

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]

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]

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

• Written Post: Skeleton Next - Update 8 - Popovers and Modals #2629
• Video Walkthrough: https://youtu.be/AU0Lrs16siA

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

[jhechtf]

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

[endigo9740]

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]

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