-
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
Fix incorrect Transition
boundary for Dialog
component
#3331
Conversation
Initially we didn't do this, because it's a bit silly to do that if you already had a `Transition` component on the outside. E.g.: ```tsx <Transition show={open}> <Dialog onClose={() => setOpen(false)}> {/* ... */} </Dialog> </Transition> ``` Because this means that we technically have this: ```tsx <Transition show={open}> <Dialog onClose={() => setOpen(false)}> <Transition> <InternalDialog> {/* ... */} </InternalDialog> </Dialog> </Transition> </Transition> ``` The good part is that the inner `Transition` is rendering a `Fragment` and forwards all the props to the underlying element (the internal dialog). This way we have a guaranteed transition boundary.
This also mimics better what we are actually trying to do.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
let inTransitionComponent = usesOpenClosedState !== null | ||
if (!inTransitionComponent && open !== undefined && !rest.static) { |
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.
Now we are not relying on the OpenClosed
state from a parent to know whether we should wrap the Dialog
in a Transition
Instead, we will always do that. If you happen to already wrap your Dialog
in a Transition
on the outside, then the props will be forwarded to the underlying element because Transition
renders as Fragment
by default.
Ensure that each
Dialog
is always a newTransition
boundary such that nestedTransitionChild
components are correctly handled.If you happen to nest
Dialog
components in places where you shouldn't (e.g.: inside aDisclosure
instead of aDisclosurePanel
) then it could lead to a crash that has been fixed by this change.Fixes: #3316
Fixes: #3322