Block Editor: Add a way to absorb inspector controls from the parent #34261
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gziolo
added
[Package] Block editor
|
Size Change: +22 B (0%) Total Size: 1.04 MB
ℹ️ View Unchanged
|
gziolo
commented
Aug 24, 2021
| @@ -166,7 +166,7 @@ export function SocialLinksEdit( props ) { | |||
| ) } | |||
| </ToolbarDropdownMenu> | |||
| </BlockControls> | |||
| <InspectorControls> | |||
| <InspectorControls __experimentalExposeToChildren> | |||
There was a problem hiding this comment.
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. |
|
Nitpick: the contrast checker is bumping up against the edge of the panel:
|
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. |
mcsf
changed the title
|
@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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
editimplementation:Controls are rendered in their own group
parentthat 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.jsfiles for terms that need renaming or removal).