-
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
Block Editor: Add a way to absorb inspector controls from the parent #34261
Conversation
Size Change: +22 B (0%) Total Size: 1.04 MB
ℹ️ View Unchanged
|
@@ -166,7 +166,7 @@ export function SocialLinksEdit( props ) { | |||
) } | |||
</ToolbarDropdownMenu> | |||
</BlockControls> | |||
<InspectorControls> | |||
<InspectorControls __experimentalExposeToChildren> |
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 didn't think too much about whether it makes sense to expose these two inspector controls present in the Social Links blocks. Let's assume it's only for demo and testing purposes. I'm happy to expose other inspector controls from different blocks as part of this PR or keep it outside of the scope.
Nice work staying on this. Here's before: Here's after: Ultimately I think it's going to be okay to blur the line between which controls originate from the parent, and which are from the child block. All that matters is that you organically arrive at your destination by making intuitive changes to blocks as you go. It's possible we might find a need for delineation in the future — for example when you want to make a change that applies only to the selected block but find that it's applying to the whole block — but I'm not yet sure we'll encounter this, and it's a bridge that we can definitely cross when we get there. However just for testing purposes, and probably useful for block developers as well, it seems like it would be helpful to have a bit more clarity about which controls propogate and which do not. For example in comparing the two, the alignment and justification controls from the parent block toolbar are usefully available in the child block toolbar, but the Size control is not. Similarly, "Open links in new tab" and color options are available in the child block inspector (which is really nice 👌) — but the style variation picker is not. Do we, on a per-block basis, choose which parent controls propogate and which do not? This branch feels like a powerful example of how useful it can be to see parent options even with just a child selected, something I think can benefit the navigation block tremendously. But I wonder if the toolbar groups and inspector controls that do not propogate become less discoverable by being left out. |
I agree that it can be confusing, whether a given control applies changes only to the selected block or to the parent block plus child blocks. Another aspect to consider is that some folks might want to see the same changes to get applied only to the selected block. In the case of the Social Link block, I immediately thought that it would be nice to be able to apply changes to the color of the currently selected block but instead, it applies modifications to all siblings, too 😅
Good point, Size was in a different toolbar group so I missed it. We can always expose it, but it will land in a single toolbar group for parent controls. So that's a limitation of the current experiment. |
@jorgefilipecosta continues similar exploration in #42684 so I will close this one as it is less advanced. He takes a different approach where you can navigate between blocks in the sidebar: Jul-25-2022.2018-53-10.mp4Jul-25-2022.2018-54-45.mp4 |
Description
Exploration for #26313.
Complementary solution for #33955 that implements absorbing block controls.
I enabled this new functionality for the Social Icons block that has already opted-in for the experimental supports flag that exposed controls to the block's children blocks:
gutenberg/packages/block-library/src/social-links/block.json
Line 44 in 1971a3c
Inspector controls get exposed by using the new prop in the code that defines inspector controls in the
edit
implementation:Controls are rendered in their own group
parent
that gets introduced to combine all parent controls together:How has this been tested?
See the screencast:
Screen.Recording.2021-08-24.at.12.28.43.mov
Types of changes
New experimental feature (non-breaking change which adds functionality).
Checklist:
*.native.js
files for terms that need renaming or removal).