Menu: migrate Storybook examples to CSF3

[ciampo]

What?

Migrate Menu's storybook examples to the latest story format

Why?

Keeping aligned with latest Storybook specs and features, potentially better performance

How?

Followed docs at https://storybook.js.org/docs/api/csf

Testing Instructions

Build storybook locally (npm run storybook:dev), make sure that all Menu stories work as on trunk

[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: ciampo <mciampini@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

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

[ciampo]

Hiding whitespace changes removes a lot of noise while reviewing

[github-actions]

Flaky tests detected in 2514423.
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/12435183705
📝 Reported issues:

• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js

[tyxla]

This looks good, thanks for the migration @ciampo!

Just left a few questions and things to discuss as I'm getting familiar with the syntax.

[tyxla]

Is there a good reason for this change?

When I run the csf-2-to-3 codemod it keeps that type above, as it was in CSF2.

Try it out on trunk:

npx storybook@8.4.7 migrate csf-2-to-3 --glob="packages/components/src/menu/stories/index.story.tsx"

[mirka]

Also curious. I'd prefer to keep doing it the old way for consistency, if there are no benefits. (I noticed someone recently used satisfies for the Badge stories.)

[tyxla]

The csf-2-to-3 codemod would use render: () => { ... } instead of args.children. What's the difference? Seems like it allows you to specify the props type inline when passing it to render:

export const Default: StoryObj< typeof Menu > = {
	render: ( props: MenuProps ) => (
		<Menu { ...props }>
			/// ...
		</Menu>
	),

	args: {},
};

One difference to note is that the codemod uses render: but also specifically adds this to all stories that inherit from Default:

	args: {
		...Default.args,
	},

[mirka]

When I was working on some of the TypeScript compilation hotspots, I noticed that not having a render function is better for performance, since it can bypass a lot of work. So we should avoid render and prefer children when possible.

[tyxla]

Why do we need to provide a named function here? Can't we just do:

	render: ( props: MenuProps ) => (
		<>
			//...
		</>
	),

[ciampo]

I used named functions to prevent warnings about using hooks outside of a component.

[mirka]

Also curious. I'd prefer to keep doing it the old way for consistency, if there are no benefits. (I noticed someone recently used satisfies for the Badge stories.)

[mirka]

When I was working on some of the TypeScript compilation hotspots, I noticed that not having a render function is better for performance, since it can bypass a lot of work. So we should avoid render and prefer children when possible.

[mirka]

These parameter types shouldn't be necessary, since that is already handled through the StoryObj<> generic.

Suggested change

	render: function WithCheckboxes( props: MenuProps ) {
	render: function WithCheckboxes( props ) {

[mirka]

Any reason it's not this?

Suggested change

	type Story = StoryObj< MenuProps >;
	type Story = StoryObj< typeof Menu >;