Description

Exploration for #26313.

One apparent difficulty that has risen with more and more blocks leveraging child blocks for controls (Buttons, Social Icons, Navigation, etc) is a general lack of intuitiveness when it comes to modifying attributes of the parent. Example: changing the alignment of Buttons when editing a single Button; changing the color of Navigation (a parent block attribute) when editing a single Navigation Item.
To address this, I'd like to explore ideas around when and how the toolbar and sidebar controls of a parent block could be exposed on their children. There are many challenges around clarity to overcome. This should not be a default true property, since groupings like Group, Columns, Cover, etc, should not present this behaviour.

This PR explores changes for the Buttons and Social Icons blocks. The very first iteration tries passing an experimental flag __experimentalExposeToChildren in BlockControl usage in the edit implementation of the parent block. It takes advantage of the SlotFill behavior and conditionally renders the control in the child block when it's selected.

The behavior is limited to the child block at the moment, but we could also cover ancestors if we would like to go one step further. The challenge is how to handle blocks that can be nested in themselves, but I think it's doable if we feel more adventurous. The current approach is enough for the Buttons and Social Icons blocks that have a very simple parent-child relation.

Please note that I also used __experimentalCaptureToolbars flag for the inner block containers so the toolbar is always present in the same place like in the Navigation block.

It should be possible to use the same technique for Inspector Controls.

How has this been tested?

See the screencast:

I used multiple blocks of the same type to ensure that the control isn't present multiple times in the child block. I was able to ensure that the control updates only the parent block.

Knows Issues

Everything works perfectly fine for the Buttons block.

There is something strange happening with the Social Icons block that needs further investigation but it seems to be present in the trunk as well.

I still need to figure out how to handle controls that get injected through block supports like align.

Open Questions

Where should be parent controls located? It's the same group as in the parent in the prototype. Should we create a special group? Where should it be placed?

In the Buttons block, you can see controls from the parent (items justification) mixed with those from the child (link). If we would move parent controls to their own group we would make it more clear what we edit. We could even move this group next to the Select Buttons (Select parent) button to make it even more glued together.

Types of changes

New feature (non-breaking change which adds functionality).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).