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: ciampo <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: oandregal <[email protected]>

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

Size Change: +235 B (+0.01%)

Total Size: 1.84 MB

_{compressed-size-action}

Flaky tests detected in 3949e54.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12349870891
📝 Reported issues:

• [Flaky Test] submenu click on the arrow interactions #61884 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

Update: I managed to fix the CI issue by increasing the memory used by node.

@WordPress/gutenberg-components I think this is a good time to have a first round of review and collect some feedback:

• what do you think about the new proposed components / APIs? Does the split make sense?
• what do you think about the sub-component names?
• any props missing?
• what do you think about the new DX of adding menu triggers? And what about sub-menu triggers?
• any good ways to split this PR in smaller PRs?

You may want to give a quick smoke test to Storybook and the editor too.

any good ways to split this PR in smaller PRs?

How about we split this into a stacked PR, with each integration change as a separate sub-PR?

any good ways to split this PR in smaller PRs?

How about we split this into a stacked PR, with each integration change as a separate sub-PR?

Sure, I can do that!

I'd still like to gather any high-level feedback before breaking the PR into smaller one, if folks have any.

The one high-level question I have is about having a submenu trigger component separate from the root-level trigger component. For example in the submenu example in Ariakit it's switching based on store.parent, and in your proposed code it's reading that property as well. What are the benefits of having separate components, as opposed to a single Menu.TriggerButton component?

in the submenu example in Ariakit it's switching based on store.parent, and in your proposed code it's reading that property as well

That's basically the logic that the component currently implements on trunk when exposing the trigger prop.

What are the benefits of having separate components, as opposed to a single Menu.TriggerButton component?

• The two components are based on different semantics / HTML elements (button vs menuitem) and therefore could potentially accept different props;
• keeping two separate components allows us to pick names that more tailored for their semantics (again, menu button vs submenu trigger item)
• In terms of DX, to someone reading the code, seeing a dedicated submenu trigger item clearly indicates that they are looking at a nested submenu, and hopefully suggests that they could use sub-components like Menu.ItemLabel as children, and props like prefix and suffix

Rebased to solve confilict — note that the global styles preview/style book menu has been removed in favour of a toggle