PluginMoreMenuItem implementation does not render MenuItem as expected

[AnthonyLedesma]

Description

Using the following implementation - I expect the plugin menu item to be rendered as a MenuItem as indicated in the docs for the props.other declaration. Unfortunately, this approach is rendering only a basic Button dom element which seems to be the default for the ActionItem component.

import { PluginMoreMenuItem } from '@wordpress/edit-post';

...
	return (
		<>
			<PluginMoreMenuItem onClick={ openModal }>
				{ __( 'Editor settings', 'coblocks' ) }
			</PluginMoreMenuItem>
			...
		</>
		)

I've found an alternate route that allows us to insert MenuItem components using the following:

/**
 * WordPress dependencies
 */
import { ActionItem } from '@wordpress/interface';
import { compose } from '@wordpress/compose';
import { MenuItem } from '@wordpress/components';
import { withPluginContext } from '@wordpress/plugins';

export default compose(
	withPluginContext( ( context, ownProps ) => {
		return {
			as: MenuItem,
			icon: ownProps.icon || context.icon,
			name: 'core/edit-post/plugin-more-menu',
		};
	} )
)( ActionItem );

By being able to use the MenuItem we gain the benefits of existing work done to handle aria attributes for example among other benefits such as styling consistency.

Here are a few helpful links to the related codebase.

gutenberg/packages/edit-post/src/components/header/plugin-more-menu-item/index.js

Lines 66 to 69 in 8001881

	return {
	icon: ownProps.icon || context.icon,
	name: 'core/edit-post/plugin-more-menu',
	};

gutenberg/packages/interface/src/components/complementary-area-more-menu-item/index.js

Lines 18 to 28 in 58d74b6

	const PluginsMenuItem = ( props ) => (
	// Menu item is marked with unstable prop for backward compatibility.
	// They are removed so they don't leak to DOM elements.
	// @see https://github.com/WordPress/gutenberg/issues/14457
	<MenuItem
	{ ...omit( props, [
	'__unstableExplicitMenuItem',
	'__unstableTarget',
	] ) }
	/>
	);

(Show MenuItem implementation)

Step-by-step reproduction instructions

This is a code related bug and is reproducible with the following example code

import { PluginMoreMenuItem } from '@wordpress/edit-post';

...
	return (
		<>
			<PluginMoreMenuItem onClick={ openModal }>
				{ __( 'Editor settings', 'coblocks' ) }
			</PluginMoreMenuItem>
			...
		</>
		)

Screenshots, screen recording, code snippet

Environment info

WP 5.9.2
GB N/A
CoBlocks 2.22.4

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[talldan]

@AnthonyLedesma That's a good point. Given the component is named MenuItem it's probably a bit deceiving that it's not rendering a menu item.

As a temporary workaround are you able to do something like this in your plugin?

import { MenuItem } from '@wordpress/components';
import { PluginMoreMenuItem } from '@wordpress/edit-post';

...
	return (
		<>
			<PluginMoreMenuItem as={ MenuItem } onClick={ openModal }>
				{ __( 'Editor settings', 'coblocks' ) }
			</PluginMoreMenuItem>
			...
		</>
        )

Your proposed fix makes sense to me, is that something you'd be willing to contribute in a PR? The only change I'd make is to have MenuItem as the default value, but still allow as to be overridden by the implementor. For example:

export default compose(
	withPluginContext( ( context, ownProps ) => {
		return {
			as: ownProps.as ?? MenuItem,
			icon: ownProps.icon || context.icon,
			name: 'core/edit-post/plugin-more-menu',
		};
	} )
)( ActionItem );

[AnthonyLedesma]

Good call @talldan. It looks like passing in as={ MenuItem } as you have proposed in your example code does the job of rendering a MenuItem as expected.

I can work on a PR to make that MenuItem a default unless overridden.