-
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
Make useBlockEditingMode() public #52094
Conversation
Size Change: -88 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
4cf09e9
to
5b1e455
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.
The changes look good, and I couldn't spot any regression page content focus.
We'll need to audit the getBlockEditingMode
and remove the unlock
wrapper where unnecessary.
Here are a few examples:
- https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/block-editing-mode/index.js#L52
- https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/block-inspector/index.js#L38-L42
- https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/block-list/block.js#L101-L105
There's more when you search the codebase.
All done @Mamaduka 👍 |
6a4d00c
to
0f57c17
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.
Thanks for the follow-up, @noisysocks!
The changes look good to me. I smoke-tested the page/template editing in the Site Editor.
0f57c17
to
bc79a32
Compare
✍🏻 Dev noteNew public hook in the Block Editor API: useBlockEditingMode()Blocks can set an editing "mode" using the useBlockEditingMode hook.
The block editing mode can be one of three options:
The block editing mode is inherited by all of the block's inner blocks, unless inner blocks have their own modes set. Usage: function MyBlock( { attributes, setAttributes } ) {
useBlockEditingMode( 'disabled' );
// MyBlock will be marked as 'disabled' editing mode.
return <ChildComponent { ...useBlockProps() }></ChildComponent>;
}
function ChildComponent( props ) {
const blockEditingMode = useBlockEditingMode();
let text = 'Child component';
if ( blockEditingMode === 'disabled' ) {
// Block is disabled, add custom block properties to indicate disabled mode.
text+= ' is disabled!';
}
if ( blockEditingMode === 'default' ) {
// Block can be edited, show controls or other editing-related settings.
<MyBlockCustomControls />
}
return <div { ...props }>{ text }</div>;
} |
Why do extenders need this? |
I think to check the block editing mode and hide controls based on it. Some of the core blocks do the same. |
I can't help but feel these API weren't ready to be public. And now we'll have to support them forever. Why should a block be able to disable itself through |
Yeah. We probably rushed making this public :/ Here's one example in the core that uses |
@ellatrix I cannot speak to if this was rushed or not. But I can speak to why we need it. Id you are building a custom block that should work and expose a subset of controls inside a Yeah there is the never official way of adding |
What?
Makes
useBlockEditingMode()
(see #50643) public so that extenders can use it. The accompanying selector (getBlockEditingMode
) and actions (setBlockEditingMode
,unsetBlockEditingMode
) are also made public.Why?
A few folks have reached out to me asking for this as they'd like to use it in their plugins.
The only reason it's private is because I want the API to have time in the Gutenberg plugin where we can iterate on it before we merge it to Core and have to maintain backwards compatibility forever. WP 6.3 was too near when the API was added. By making this public now the API will be available for use by extenders in the next Gutenberg plugin release and then in WP 6.4.
Testing Instructions
Nothing specific. Check for regressions to the Page Content Focus functionality.