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:
Two specific use cases for this might be:
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.
Update: @jorgefilipecosta this looks to have been fixed in
When the toolbar moves to the parent the black line at the side should also move otherwise there is a visual disconnect.
@jorgefilipecosta I've been thinking more about this. I'm not totally convinced that moving the indicator is optimal for user experience.
For example, if I were to do this how would I know that I've hovered/selected the child block? The only indicator would be the block movers which I feel is insufficient.
Perhaps I can suggest we simply tweak the position of the focus/select indicator so it is placed in a nicer way. See below.
(about to rebase this)