Stack dialogs and their overlays above whatever else is open - #251
Merged
Conversation
Dialog, Dropdown, DatePicker, and Tooltip each used a single static z-index token, so a second dialog opened while the first is still visible collided on the exact same value - which one painted on top was incidental DOM order, not a deliberate stacking rule. A dropdown or date-picker opened inside that second dialog had the same problem one level down: it stacked above its own dialog's static tier, but not above a dialog elevated beyond that tier. This is the gap left behind when Components 4 moved Dialog/Dropdown/ DatePicker off PrimeReact and onto React Aria: PrimeReact's own ZIndexUtils registry used to assign each newly opened overlay a strictly higher value, and the old useOverlayZIndex hook only ever backstopped that registry with a floor - it relied on PrimeReact doing the real work, so nothing replaced it when PrimeReact did. Add a small open-dialog registry (openDialogTier/closeDialogTier) that assigns each currently visible dialog a strictly increasing tier regardless of where in the tree it was opened from, and a DialogStackContext dialogs provide their resolved z-index through so Dropdown/DatePicker/Tooltip can stack their own popovers relative to whichever dialog tier they are actually nested in, rather than a single static overlay token that only ever accounted for one. A single, non-nested dialog is unaffected - it still resolves to the same 1100/1200 values the static tokens produced before.
Common (Tooltip, DatePicker) importing from Dialogs crossed a hard module-graph boundary the package's own CI enforces: a slot family's private internals stay private to that family, and only the neutral renderer/ layer is meant to be shared across families - exactly what RendererContext.tsx already is for unstable_useOverlayEnvironment, which every one of these four implementations already imports from there. dialogStack.ts and DialogStackContext.ts have no dependency beyond React, so they belong there for the same reason.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixed
Context
Components 3 kept overlay panels above their dialog with
useOverlayZIndex, a raise-only floor over PrimeReact's ownZIndexUtilsregistry (#123, PR #117, 2.6.2). Components 4 moved Dialog/Dropdown/DatePicker off PrimeReact onto React Aria, anduseOverlayZIndexwas removed as redundant along with everything else PrimeReact-specific - but nothing replaced the registry it depended on. A single dialog was never affected (there was only ever one static tier to stack above), which is why this went unnoticed: it only shows up with two dialogs open at once, or an overlay opened from the second one.Adds a small open-dialog registry (
Source/Dialogs/dialogStack.ts) that assigns each currently visible dialog a strictly increasing tier regardless of where in the tree it was opened from, and aDialogStackContextdialogs provide their resolved z-index through so nested overlay-producing components can stack relative to their actual dialog tier instead of a single static token. Internal wiring only - no public API change, so this ships as a patch.