-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Don't break overflow when multiple dialogs are open at the same time #2215
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments / questions. In general I'm really happy the code works, the implementation is quite big/heavy but that's fine but I wonder if there are some things we can improve or make more generic and use a more generic middleware
system. Somehow. 😅
packages/@headlessui-react/src/hooks/document-overflow/adjust-scrollbar-padding.ts
Outdated
Show resolved
Hide resolved
packages/@headlessui-react/src/hooks/document-overflow/adjust-scrollbar-padding.ts
Outdated
Show resolved
Hide resolved
565564c
to
1640494
Compare
When using
<Transition>
+<Dialog>
and you switch between two dialogs on the page you end up with a brief period where multiple dialogs are open at the same time. This is a situation that we do not support.However, in an ideal world this shouldn't break document scrolling so here I've implemented a global store of sorts that we can subscribe to and update components accordingly. This allows us to keep track of a global counter detailing how many things are keeping the document scroll-locked and we'll only enable / disable scroll locking when there is at least one open dialog on the page and only disable it when the number of open dialogs reaches zero.
This has yet to be ported to Vue but I suspect that'll be a good bit simpler to do b/c it has native reactivity that can happen outside of components. We want to make sure the behavior for this is: 1. as expected; and 2. doesn't break any of the fixes we have in place for browser bugs.
Fixes #2168