Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Experimental: allow parent Block to consume child Block's toolbar #18440
Several recent use cases have suggested that it would be valuable to a parent Block rendering child blocks into
The key benefits of this are:
Update: for use case please see Joen's comment below.
In general however, the pattern also lends itself well to any deeply nested Block hierarchies. For example, on the current
By deferring the rendering of all toolbars to the root block of the hierarchy we provide a better experience.
The PR is experimental and achieves the effect by:
The reason for using Slot/Fill is due to needing to capture events triggered on the childtoolbar within the React component tree rather than the DOM tree. If we allow for the events to bubble in the DOM it triggers selection of the underlying parent Block (which is where the Slot is rendered) which breaks a lot of toolbar functionality.
This works. There are some quirks that would need to be worked out.
I'm looking for feedback about:
How has this been tested?
Manual testing for now.
Also try switching out the boolean props on
Also try applying these props to the
Types of changes
New feature (non-breaking change which adds functionality)
Nice work thank you!
This is what I see:
The shift in height on menu item select is a separate issue to this PR, but worth looking at.
I think this is good:
In that vein,
I would echo @talldan in suggesting that we might need some visual adjustment. There was something accidentally nice in having the toolbar centered over each menu item — that relationship would be nice to explore restoring. And also, the style of each selected child item can probably be holistically considered. But none of those explorations, IMO, should happen in this PR. What this does is essentially replace the hacky CSS that was written for the Navigation Block and Social Links blocks, to "mimic" this behavior in absence of this prop.
In that vein, it might be worth looking at how much of that code we can now remove and clean up, now that it's official. For example, #17877 might make the horizontal margin work simpler, and lines 14-68 in https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/social-links/editor.scss#L14 and 1-55 in https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/navigation-menu/editor.scss SHOULD be made redundant by this PR. I'm not they are, but they should be :)
Agreed. Looks like hovering/clicking anywhere outside the format controls triggers the underlying parent Block to be selected.
It's because the toolbar is rendered outside the selected Block. As a result, any clicks on items will be equivalent to clicking outside the Block. As the parent Block is "underneath" the child block then the result is that this parent Block becomes selected.
The reason why the bold/italic...etc buttons don't have this issue is because they are rendered via SlotFill and make use of the
If you set the
The issue, therefore, is working out how to stop these DOM events from bubbling.
I'm starting to look into whether wrapping the Toolbar which omits the offending
I'm wondering whether to wait on the below to land before we try and spend too much time fixing the current implementation:
Previously we were rendering x2 toolbars which cause the ref associated with forcing toolbars to become out of sync. This meant that using keyboard shortcuts to focus the toolbar didn’t work. Fixed by rendering component on demand.
I wish Github didn't hide comments when there are enough of them. The explanation as a result was buried here: #18440 (comment)
The gist of it is this:
You can create any number of crazy child blocks. Rotate them, squish them, filter them, invert them, make them so small or so big that an attached toolbar just doesn't make sense.
I realize the context of removing the toolbar from the DOM potentially enabling the rotation of the block without also rotating the toolbar, but I believe there is still a use case for some blocks to have a toolbar attached to the parent block.