-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Double click block to exit zoom out mode #64573
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: +78 B (0%) Total Size: 1.78 MB
ℹ️ View Unchanged
|
I like this, and it makes sense to me. I don't see this happening by mistake easily. @richtabor I'd like your thoughts on this one. |
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.
A double click to exit will be really useful!
packages/block-editor/src/components/block-list/use-block-props/use-zoom-out-mode-exit.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/block-list/use-block-props/use-zoom-out-mode-exit.js
Outdated
Show resolved
Hide resolved
Flaky tests detected in 62707d0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10504914533
|
event.preventDefault(); | ||
|
||
__unstableSetEditorMode( 'edit' ); | ||
selectBlock( clientId ); |
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.
This should already be selected due to the focus handler in block props selecting the block. Could we remove the selectBlock
and leave a comment about where the block selection happens?
const { __unstableSetEditorMode, selectBlock } = unlock( | ||
useDispatch( blockEditorStore ) | ||
); | ||
|
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.
Zoom out mode is fairly rare right now. Rather than adding a double click to all blocks, could we early return here if we're not in zoom out? That way, we only add these listeners when it's useful?
@jeryj If you have time / inclination to make the changes you suggest please go ahead. Otherwise I'll pick it up during this week 🤞 |
972c690
to
5d89474
Compare
…steners Reducing the number of useSelect calls and event listeners is important for performance. Rather than have a useSelect to check zoom out mode and add event listeners to every block, let's do the useSelect once in the provider and pass it in to the hook, and only add the event listener if we're in zoom out mode.
The block is already being selected via the useFocusHandler hook, so no need to repeat it here.
Made some changes to reduce |
@@ -728,6 +730,7 @@ function BlockListBlockProvider( props ) { | |||
themeSupportsLayout, | |||
isTemporarilyEditingAsBlocks, | |||
blockEditingMode, | |||
editorMode, |
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.
As we're touching the deps, we should monitor the editor performance after merging this PR.
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 was remembering #56994 about combining block store subscriptions, and assumed it would be better to add it here rather than check on each block. Maybe the performance potential isn't worth it though. I do like the implementation though, as it makes the final result quite clean.
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.
That's a good point about combining store subscriptions. Let's try it "as is" and watch the performance charts post-merge.
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 did some smoke test with running performance in the inspector and entering into/out of zoom out mode and this method of using the combined subscription and not adding listeners was always faster in both total scripting and rendering, so I say we go with it as well.
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.
Great. I say we merge it and then watch the performance dashboard in case of any changes post-merge.
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.
@jeryj Notice any problems in the Dashboard? I'm not seeing any.
packages/block-editor/src/components/block-list/use-block-props/use-zoom-out-mode-exit.js
Show resolved
Hide resolved
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.
UX this seems to work well.
I'm unsure if we need the changes to the block's props or whether we can just check the editor mode in the hook.
@jeryj I can't approve my own PR but this feels pretty solid right now. |
|
||
return useRefEffect( | ||
( node ) => { | ||
if ( editorMode !== 'zoom-out' ) { |
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.
Instead of having the editorMode as a dependency of the useRefEffect and regenerating a new ref / new event listener everytime this change. We could just call getEditorMode within onDoubleClick event listener (Like we do for useNavModeExit
This would also remove the need to pass the editorMode top/down through the context...
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 seeing the opposite comment above. I think personally the performance impact of having the double click always there is less than re-rendering when the editorMode changes, it's also way simpler in terms of code. But I'm ok if you all disagree.
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 the same thought process. I believe @jeryj did some performance profiling on this so he may be able to answer more concretely.
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 done profiling on the page and not adding the event listener used a lot less resources. The metrics for typing are going up. I'm having a hard time isolating a PR that is causing it. It's odd to me that adding the mode to the block props would cause that, as the editing mode doesn't really change often and definitely isn't changed in the middle of the performance tests. I can make another branch that reworks this to this older style and we can 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.
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 don't see any major changes in performance with either approach.
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.
The typing metic was probably affected by a new store subscription. See #65337.
What?
Adds ability to exit Zoom Out mode by double clicking on the block.
Note: the accessibility implications of click handlers are discussed in
Testing Instructions for Keyboard
below.Why?
It's important experiment with intuitive ways of exiting Zoom Out mode so that users can get back to edit mode.
How?
Adds a double click handler to the block props which will exit zoom out mode if a block is clicked and we are in zoom out mode.
Testing Instructions
Testing Instructions for Keyboard
This action cannot be mirrored by keyboards. Therefore we have introduced an alternative means of exiting zoom out mode in #64571.
Screenshots or screencast
Screen.Capture.on.2024-08-16.at.10-51-12.mp4