ActionItem: Move the more menu deduplication out of the Slot

[Mamaduka]

What?

Required for #81564, when you can see the cleanup in action.

RP removes backward-compatibility deduplication from ActionItem.Slot in @wordpress/interface, adds a children render prop to the slot, and changes the as default for the fill from Button to MenuItem.

Why?

ActionItem is a generic slot and fill pair, but its slot scans every rendered fill for the __unstableExplicitMenuItem and __unstableTarget props so that a plugin rendering PluginSidebarMoreMenuItem would not get a second menu item next to the one ComplementaryArea injects for pinnable sidebars (#14457). That check only concerns ComplementaryArea, and it makes the slot hard to build on.

Note

This was extracted from WIP migration to the new Menu component (#79560) from @wordpress/ui, where the host supplies the group container and wraps each fill, which the current slot cannot express.

How?

ComplementaryAreaMoreMenuItem now registers itself in a module-level observable map keyed by scope/target, and ComplementaryArea leaves out the menu item it injects while one is registered for the same area. The duplicate is never rendered, so the slot no longer needs to filter anything. ActionItem.Slot takes an optional children function that receives the fills as a flat array and replaces the as container, which is the seam the Menu migration needs. Both __unstable* props are still accepted on ComplementaryAreaMoreMenuItem, so they do not reach the DOM, but nothing reads them.

Dropping the Button default lets three call sites stop passing as explicitly, since MenuItem is what they all want.

Testing Instructions

Automated coverage is in test/e2e/specs/editor/plugins/plugins-api.spec.js.

Testing Instructions for Keyboard

Same.

Use of AI Tools

Assisted by Claude.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: -48 B (0%)

Total Size: 7.91 MB

📦 View Changed

Filename	Size	Change
build/scripts/edit-widgets/index.min.js	22.5 kB	-36 B (-0.16%)
build/scripts/editor/index.min.js	578 kB	-12 B (0%)

_{compressed-size-action}

[ciampo]

cc @jsnajdr in case you can take a look here, it could use your expertise / experience with slot fill

[ciampo]

Should we keep this registration provider-local? Each SlotFillProvider owns an independent Fill registry, but this module-level map is shared by every provider.

Potential scenario: If provider A renders an explicit item for core/foo, every ComplementaryArea for core/foo sees this global entry, including one in provider B. Provider B then removes its injected item even though A's Fill cannot reach B's Slot, so B can lose its only More Menu entry for that sidebar.

A focused reproduction is two SlotFillProvider roots with the same scope and target: only the root containing the explicit item should suppress its default item. Scoping the state to the active provider, or doing the filtering at the concrete provider-local ActionItem.Slot, would preserve the old isolation and avoid the global map/effect/ref-count machinery.

[Mamaduka]

Valid case, but will this actually happen in practice? The registerPlugin used by the consumer to add plugin sidebar or menu items is also global.

[ciampo]

Yes, although it may still applicable. registerPlugin is global, but its rendered UI and SlotFill registry are provider-local. This map is too global across providers, so provider A can hide provider B's only item.

It is also too local across bundles: @wordpress/interface is bundled, so a plugin and the host can use separate maps while sharing the same externalized SlotFill registry. That leaves duplicates and breaks old/new package combinations once the markers are removed.

I guess we should keep the markers and filter at the concrete core/plugin-more-menu ActionItem.Slot? That preserves provider and bundle/version isolation.

We should be able verify the regression with a "two provider" test

[Mamaduka]

I couldn't find a way to provide a problem score in the app. Every SlotFillProvider we have is a single root, and BlockEditorProvider uses passthrough, so nested editors reuse the parent registry.

For bundles, I think #60748 covers it. The interface package registers a store on import, so a second copy already logs Store "core/interface" is already registered. That's why the editor proxies the package for edit-post and edit-site. The markers did survive duplication, but that setup is broken either way.

[ciampo]

Thanks, that makes sense. I reproduced the module-isolation behavior, but I couldn’t connect it to the documented plugin path or a current app setup. Since #60748 keeps that path on one Interface copy, I don’t think this should block the PR.

We can always come back to this at a later point since the new map, hook, and default-item component are internal.

[Mamaduka]

Thanks, @ciampo!

I need to sync some changes made in #81564, but I think a separate PR makes this easier to review.

[Mamaduka]

The branch is up to date, and I think I've handled the remaining feedback. While #81564 was the inspo for this cleanup, I think it can be landed separately, which reduces noise in other PR.

[ciampo]

I believe this is in a good place 🚀

Not sure if @jsnajdr has any additoinal feedback

[ciampo]

Could we document the new ActionItem.Slot.children( items ) and fillProps.as APIs in the Interface changelog? The editor wrapper changes also potentially need an Internal entry.

[Mamaduka]

Funny you should ask. I initially listed those as changelog entries but dropped them after recent rebasing because the list was growing too much.

The first two items are documented in the README. The last one seemed very internal and not concerning any other consumers.

[Mamaduka]

If there are no blockers, I'll merge and continue working on the linked refactoring PR.

[jsnajdr]

Found one little docs issue on my final look, can be addressed in one of the follow-up refactorings.

[jsnajdr]

This documentation is not precise:

Props passed to every fill.

Technically true, but an internal detail invisible in the public API. The consumer writes <ActionItem name as onClick> markup, there is no fill to be seen. fillProps passed to the ActionItem.Slot in fact provide default as for the ActionItems rendered in that slot, and and additional onClick handler for each ActionItem. In other words, the fillProps get merged, with a different algo for each props, into each ActionItem in the slot.

[Mamaduka]

Included changes in menu refactoring PR.