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

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

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

I see. The rules of hooks are broken because React doesn't know how to statically treat hooks inside a dynamically assigned function component like this - it just can't possibly guarantee if render() is not going to be passed around, which would break rules of hooks.

To me that's just another reason not to use this render() syntax and to use args.children if possible.

Alternatively, we could move the component declaration outside of render() and just pass an instance here - would that work better? The hack with tricking the linter bit us back and we had to change it, which is why I'm hesitant to do it once more.

I'm leaving this to your judgment, as I don't have particularly strong feelings.

My understanding was that the hooks linter simply can't know that render: () => {} is meant to be a React component. render: function UppercaseName() {} just tells the linter that it's meant to be a component, like any other function with a uppercased name.

What we're doing for render isn't that different from the way we can define subcomponents, e.g.:

// this is fine
Menu.Submenu = () => { /* something with hooks */ };

// this is not fine because lowercase
Menu.submenu = () => { /* something with hooks */ };

// would've been fine if the `render` field had been uppercase like this 😅
Default.Render = () => { /* something with hooks */ };

So while I can't say that this isn't a "hack", I don't think it's hacky in a way that's unsafe?

I've elaborated on it here, and it's definitely not unsafe, and we can move forward with it for Storybook.

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

I did that initially, but then I added back the explicit props because it seems to improve TypeScript performance (TS doesn't need to compute the prop types since they are explicitly declared)

We ran some TS profiling here, and it turned out to make a big difference. Results were similar to here:

#67422 (comment)

As I discussed with @ciampo over DM earlier, I think this has something to do with how Storybook infers component props for stories when working with compound components, and maybe the inference is not optimized to work with subcomponents and does extra cycles, resulting in infinite loop. It's worth debugging with a dev Storybook setup and an isolated story test case, IMO.

Huh, that's unfortunate!

One ideological issue I have with props: MenuProps is that MyComponentProps is often not the canonically accurate set of props in our library, because we often mix in element props with WordPressComponentProps<>. I feel like we should generally prefer React.ComponentProps< typeof MyComponent > for accuracy. Would that still work here while maintaining the performance benefits? (Not a blocker though, since element props mixed in with WordPressComponentProps<> are not going to show up as Storybook controls anyway.)

Let's try it out and measure it, but I think it should be fine, as long as we don't let Storybook infer the prop types.

What about React.ComponentProps< Menu > ? It could hit a sweet spot between accuracy and performance?

We can test it out in a separate PR, if needed