-
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
Changes from all commits
b472b19
deb4c4c
2940cb5
172f9bc
44f7824
5d89474
088f6c5
388ee4b
eab3e1b
4fdbf7c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,44 @@ | ||
/** | ||
* WordPress dependencies | ||
*/ | ||
import { useDispatch } from '@wordpress/data'; | ||
import { useRefEffect } from '@wordpress/compose'; | ||
|
||
/** | ||
* Internal dependencies | ||
*/ | ||
import { store as blockEditorStore } from '../../../store'; | ||
import { unlock } from '../../../lock-unlock'; | ||
|
||
/** | ||
* Allows Zoom Out mode to be exited by double clicking in the selected block. | ||
* | ||
* @param {string} clientId Block client ID. | ||
*/ | ||
export function useZoomOutModeExit( { editorMode } ) { | ||
getdave marked this conversation as resolved.
Show resolved
Hide resolved
|
||
const { __unstableSetEditorMode } = unlock( | ||
useDispatch( blockEditorStore ) | ||
); | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? |
||
return useRefEffect( | ||
( node ) => { | ||
if ( editorMode !== 'zoom-out' ) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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 commentThe 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 commentThe 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 commentThe 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 commentThe 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 commentThe 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. |
||
return; | ||
} | ||
|
||
function onDoubleClick( event ) { | ||
if ( ! event.defaultPrevented ) { | ||
event.preventDefault(); | ||
__unstableSetEditorMode( 'edit' ); | ||
} | ||
} | ||
|
||
node.addEventListener( 'dblclick', onDoubleClick ); | ||
|
||
return () => { | ||
node.removeEventListener( 'dblclick', onDoubleClick ); | ||
}; | ||
}, | ||
[ editorMode, __unstableSetEditorMode ] | ||
); | ||
} |
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.