-
Notifications
You must be signed in to change notification settings - Fork 4.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
List View: Try directing focus to the list view toggle button when closing the list view #54175
Merged
andrewserong
merged 6 commits into
trunk
from
try/list-view-set-focus-on-toggle-button-when-closed-by-escape-key
Sep 20, 2023
+148
−100
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
8840bd1
List View: Try directing focus to the list view toggle button when cl…
andrewserong c3216b2
Only focus if no blocks are selected
andrewserong e8271c0
Also use focus logic for when the list view is closed via the keyboar…
andrewserong 53f0a7f
Try implementing in the site editor, too
andrewserong 5175627
Always return focus to the toggle whenever the list view is closed, r…
andrewserong 22f6851
Update e2e tests
andrewserong File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
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
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
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.
Passing a
useState
callback seems fine to me. It's a stable reference.I was just wondering if it would cause some cognitive confusion for anyone in the future trying to access
current
.Another question might be: is
listViewToggleElement
(the state value) a value that’s needed for rendering the component in which it lives, and would it trigger an unnecessary re-render if set?This is all purely academic, and I'm only raising because I don't know myself! Something like this might be an alternative to
useState
in layout for example.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.
Thanks for taking a look @ramonjd, and good question! I mostly went with
useState
for consistency with some of the existing places where we're using ref callbacks to store elements in state (e.g. setDropZoneElement here). In terms of trying to avoid confusion and whether or notcurrent
is available, I think so long as the variable is named withElement
as its suffix instead ofRef
, it'll hopefully be clear enough — or at least consistent enough with the other usage in the repo. Did you have any instances in mind where folks might reach forcurrent
and get tripped up?In terms of re-renders, one of the benefits of going with state is that the consumer (
list-view-sidebar.js
) is fairly straightforward in that we can placelistViewToggleElement
in the dependency arrays ofuseCallback
s and know that those callbacks will always be using the appropriate current value, without having to do any further introspection.Some of the feedback I've gotten on previous PRs that looked at using refs with elements were to prefer using state... looking the references for that up now (if you'll excuse the pun 😄), I think the linked docs were in the floating UI library, so was more to do with working with popovers (docs, and talked about in #43335), so might not be strictly speaking applicable here.
In any case, from the perspective of the list view sidebars, it feels a tiny bit neater to me if we're accessing the element directly in the component's props, rather than using a ref there, but happy to look into changing things if folks would prefer, especially if I've accidentally introduced re-renders in this PR where I shouldn't have!
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 appreciate the follow up explanation. Good to know there's a precedent. I've seen it in other libraries too, so TIL it's a thing for Gutenberg too. 🙇🏻