feat(menu): support menu modes

[janhassel]

Closes #14770

Adds the menu modes "basic" and "full" described in #14770 to support icons in MenuButton and ComboButton while restricting the use of nested and selectable items.

Opening as draft PR as the error throwing should be added to the unit tests, but first I wanted to clarify if throwing errors in this case is aligned to the Carbon ecosystem. A potential issue I see with this is that the errors are defined in MenuItem and therefore only throw once the MenuButton or ComboButton is opened.

Changelog

New

• Added props.mode to Menu and its context
• Throw errors when invalid Menu combinations are used

Testing / Reviewing

• Manual testing for now (add MenuItemSelectable or MenuItemRadioGroup as children to MenuButton and ComboButton)
• Automated testing tbd

[netlify]

✅ Deploy Preview for v11-carbon-react ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	5bb62c5
🔍 Latest deploy log	https://app.netlify.com/sites/v11-carbon-react/deploys/655fad116eb8f80008a71755
😎 Deploy Preview	https://deploy-preview-14793--v11-carbon-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	53b2a3c
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/654beb50a2808f00083ddf8a
😎 Deploy Preview	https://deploy-preview-14793--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tay1orjones]

Thanks for submitting this @janhassel! Sorry for the delay in reviewing.

The biggest concern I have with throwing an error is that if this were to happen in production, React would completely unmount everything. Devs should be using ErrorBoundary to prevent this, but it's not guaranteed.

Instead of throwing an error, I think it might make more sense to pop a console.warn and scope that error to only when in a development environment. This would follow the same approach used for deprecations via the deprecate() helper. This relies on the internal warning helper that could be used directly instead of throwing the error. It has the built in invariant check for __DEV__ so these would only pop in non-production environments:

carbon/packages/react/src/internal/warning.js

Lines 10 to 27 in 36685a0

	const warning = __DEV__
	? function warning(condition, format, ...args) {
	if (format === undefined) {
	throw new Error(
	'`warning(condition, format, ...args)` requires a warning ' +
	'format argument'
	);
	}
	if (!condition) {
	let index = 0;
	const message = format.replace(/%s/g, () => {
	return args[index++];
	});
	console.warn('Warning: ' + message);
	}
	}
	: emptyFunction;

[tay1orjones]

Thanks, this looks good to me!

[andreancardona]

apologies for the delay on this @janhassel I was OOO for a few days. Looks good 😎

[janhassel]

@andreancardona It looks like the auto-merge was cancelled. Could you take a look?