Fix crash when using DisclosureButton inside of a DisclosurePanel when the Disclosure is open by default
#3465
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
The `PopoverButton` and `DisclosureButton` act as a `CloseButton` when used inside of a panel. We conditionally handled the `ref` when it's inside a panel. We wanted to make sure that the callback is stable and used `useEvent`. This seemed to be ok (even though we break the rules of hooks) because a button can only be in a panel or not be in a panel, but it can't switch during the lifetime of the button. But it can, because the way we know whether we are in a Panel relies on a state value which comes from context. The reason we didn't catch this in the `Disclosure`, is because all the state is stable and known by the time the `Panel` opens. But if you use the `defaultOpen` prop, it is already open and then the state is not ready yet. Long story short, moved the `isWithinPanel` check inside the `useEvent(…)` hook that holds the stable function which means that we don't call this hook unconditionally anymore.
RobinMalfait
force-pushed
the
fix/default-open-disclosure-button
branch
from
9daf984 to
8b4350f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR fixes an issue where React hooks were called unconditionally>
The
PopoverButtonandDisclosureButtonact as aCloseButtonwhen used inside of a panel. We conditionally handled therefwhen it's inside a panel. To ensure that the callback is stable, the conditionally used function was wrapped in auseEvent(…)hook.This seemed to be ok (even though we break the rules of hooks) because a button can only be in a panel or not be in a panel, but it can't switch during the lifetime of the button. Aka, the rules of hooks are not broken because all code paths lead to the same hooks being called.
But... it can be called conditionally, because the way we know whether we are in a panel relies on a state value which comes from context and is populated by a
useEffect(…)hook.The reason we didn't catch this in the
Disclosurecomponent, is because all the state is stable and known by the time theDisclosurePanelopens. But if you use thedefaultOpenprop, theDisclosurePanelis already open and then the state is not ready yet (because we have to wait for theuseEffect(…)hook).Long story short, moved the
isWithinPanelcheck inside theuseEvent(…)hook that holds the stable function which means that we don't call this hook unconditionally anymore.