Block Editor: Introduce stable BlockSettingsMenuControls slot

[gziolo]

Description

Part of #20116.

It refactors __experimentalBlockSettingsMenuPluginsExtension and promotes it to stable API under BlockSettingsMenuControls name. I was able to simplify the implementation a bit by moving all logic related to block-editor to the BlockSettingsMenuControls component that.

How has this been tested?

Add a few different blocks and make sure that the block settings menu works as before.

Screenshots

Types of changes

Refactoring.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• 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.

[gziolo]

@youknowriad, with all the planned changes to the block toolbar, is there still need for __experimentalBlockSettingsMenuFirstItem or can we inline it in the toolbar and call it the day? 😄

An alternative approach would be to rename it to BlockSettingsMenuInspectorControls and made it very inflexible. As far as I can tell, you would only need to pass down onToggle, isOpened and shortcutName. It makes me also wonder whether we could use withFilters instead and provide and empty component by default.

[youknowriad]

@gziolo Yes, it's still needed for now, I think we should just mark it as unstable instead of experimental and leave it.

[oandregal]

I'm thinking we may want to use a different name as to better communicate the component's intention. How about BlockSettingsMenuPlugins?

[gziolo]

I'm thinking we may want to use a different name as to better communicate the component's intention. How about BlockSettingsMenuPlugins?

I didn't go with Plugins postfix only because of all other slots in @wordpress/block-editor avoid using this keyword:

• BlockControls
• BlockFormatControls
• InspectorAdvancedControls
• InspectorControls

How about BlockSettingsMenuControls or BlockSettingsMenuItems?

[gziolo]

In I 2a10f6c try BlockSettingsMenuControls. I also added documentation.

I also have another proposal for the name BlockSettingsMenuActions.

[oandregal]

By making the slot a new MenuGroup we are introducing a visual difference (notice the separator before the reusable blocks item in the menu).

Before	After

I think this is fine, especially because that area is variable (third-parties can hook into and add new contents). Raised in case this needed a design 👍

[oandregal]

FWIW, it doesn't change the keyboard interaction.

[mtias]

Yes, this seems fine.

[oandregal]

For completeness, this is how it looks with plugins:

Plugins are added before the core utils (reusable blocks, groups), as it works today.

[gziolo]

Plugins are added before the core utils (reusable blocks, groups), as it works today.

This is a bit unfortunate. I think before we had a slot in another slot to make it work. Should we bring it back even though you (and me) liked the simplification? :)

[oandregal]

I meant that it works the same as it did! In master, the plugins are also loaded before reusable and group items. If anything, this PR visually clarifies where plugins are added due to the new separator.

[oandregal]

This breaks third-party extensibility.

This is how I've tested:

• Activate a plugin that adds a new item to the block settings (ex: blocksettingsmenu-plugin).
• Load the editor.
• I've got a WSOD kind of error (for some reason, my env is using React production builds so message isn't very useful).

[oandregal]

I've found why this isn't working for plugins and submitted a change. This is good to land after all those changes are applied.

[gziolo]

I've found why this isn't working for plugins and submitted a change. This is good to land after all those changes are applied.

Great catch @nosolosw, thanks for proposing the fix 💯

[oandregal]

Retested this and works as expected. 🚢

[gziolo]

Thanks @nosolosw for all your help!