-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add onClose property to Popover #1800
Conversation
2517552
to
c172e25
Compare
25265c1
to
8b15cae
Compare
c172e25
to
ac12910
Compare
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.
I had a query about useFocusAway
and popover close fallback behavior.
* Callback invoked when the popover is automatically closed. | ||
* Use this callback to sync local state. | ||
*/ | ||
onClose: () => void; |
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.
If the caller fails to update the local state then the open
prop will get out of sync with the actual state. We don't currently have any use cases where the caller should "ignore" the close event, so such an event probably indicates a bug. We could improve this in future by logging a warning perhaps.
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.
If the caller fails to update the local state then the
open
prop will get out of sync with the actual state. We don't currently have any use cases where the caller should "ignore" the close event, so such an event probably indicates a bug.
Yeah, this is true. And not only that, in the non-native-popover case, if they fail to update the state, the popover won't actually close at all, but at least the state in that case is still in sync.
I'm not sure what's the solution for this to be honest. Perhaps documenting it for now.
We could improve this in future by logging a warning perhaps.
Do you mean logging a warning if the native popover is closed while open
is true?
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.
I'm not sure what's the solution for this to be honest. Perhaps documenting it for now.
I would suggest to just document it as a required usage pattern for now.
Do you mean logging a warning if the native popover is closed while open is true?
I meant that a warning would be logged if the open
prop remained true in the next render after a popover is automatically closed.
One scenario that may turn out to be an issue is if the popover gets automatically re-opened for some reason before a debounced render occurs.
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.
I meant that a warning would be logged if the
open
prop remained true in the next render after a popover is automatically closed.
Gotcha
@@ -381,10 +381,8 @@ function SelectMain<T>({ | |||
[onChange, closeListbox], | |||
); | |||
|
|||
// When clicking away, focusing away or pressing `Esc`, close the listbox | |||
useClickAway(wrapperRef, closeListbox); | |||
// Close the listbox when focusing away | |||
useFocusAway(wrapperRef, closeListbox); |
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.
Should this focus-away behavior also be part of the popover's built-in fallback?
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.
I guess it would be reasonable, but for now I decided to only mimic what the native popover does by default.
If we see we always end up adding this affordance, in other use cases, we can revisit this decision and add useFocusAway
to the Popover
.
a82be3a
to
1d33e1e
Compare
} finally { | ||
externalButton.remove(); | ||
} | ||
}); |
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.
These are now covered in Popover-test
.
1d33e1e
to
f634ec2
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1800 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 68 68
Lines 1220 1231 +11
Branches 465 467 +2
=========================================
+ Hits 1220 1231 +11 ☔ View full report in Codecov by Sentry. |
src/pattern-library/components/patterns/feedback/PopoverPage.tsx
Outdated
Show resolved
Hide resolved
f634ec2
to
334e266
Compare
Add a new
onClose
mandatory prop toPopover
, which is called when clicking away or pressing Escape.When the native popover API is used, this is controlled via the
toggle
event. Otherwise, we fall back touseClickAway
anduseKeyPress(['Escape'])
.