Using a custom component asChild of DropdownMenu.Trigger does not work

[JodiWarren]

We have a somewhat complex custom Button which I'd like to use as the child of a DropdownMenu.Trigger. It just renders a button at the end, but there is a fair amount of logic to determine the contents and the styling.

I've attempted to I use it like so:

<DropdownMenu.Trigger asChild>
  <Button some="props" for="customising">
    My button contents
  </Button>
</DropdownMenu.Trigger>

While it renders fine, it doesn't actually trigger the Dropdown. I've tried creating a forwardedRef around it, as suggested in #1369. However that doesn't seem to affect it either way.

Are there any other things that you'd suggest, or any other ways of working with this? At the moment it's a blocker for us using Radix. Other libraries like Headless and Reakit have worked more smoothly, but we really like Radix's depth and breadth.

[andy-hook]

In addition to ref forwarding the custom component should also spread the rest props onto the returned element, this is required so that behavioural handlers such as onClick, onPointerDown etc can be bound to it.

So I would double check those are being passed down correctly. As mentioned in that linked comment, we do want to improve the documentation around this but I hope this helps in the meantime.

[JodiWarren]

Ah righto, I didn't realise that. Is it these properties that get passed down?

primitives/packages/react/dropdown-menu/src/DropdownMenu.tsx

Lines 119 to 147 in 9118350

	<Primitive.button
	type="button"
	id={context.triggerId}
	aria-haspopup="menu"
	aria-expanded={context.open ? true : undefined}
	aria-controls={context.open ? context.contentId : undefined}
	data-state={context.open ? 'open' : 'closed'}
	data-disabled={disabled ? '' : undefined}
	disabled={disabled}
	{...triggerProps}
	ref={composeRefs(forwardedRef, context.triggerRef)}
	onPointerDown={composeEventHandlers(props.onPointerDown, (event) => {
	// only call handler if it's the left button (mousedown gets triggered by all mouse buttons)
	// but not when the control key is pressed (avoiding MacOS right click)
	if (!disabled && event.button === 0 && event.ctrlKey === false) {
	context.onOpenToggle();
	// prevent trigger focusing when opening
	// this allows the content to be given focus without competition
	if (!context.open) event.preventDefault();
	}
	})}
	onKeyDown={composeEventHandlers(props.onKeyDown, (event) => {
	if (disabled) return;
	if (['Enter', ' '].includes(event.key)) context.onOpenToggle();
	if (event.key === 'ArrowDown') context.onOpenChange(true);
	// prevent keypresses from scrolling window
	if ([' ', 'ArrowDown'].includes(event.key)) event.preventDefault();
	})}
	/>

We would need to whitelist these as we don't normally allow prop spreading in our code.

[andy-hook]

Yes exactly. All of the accessibility and functional behaviour that Radix needs are forwarded via props and ref.

https://codesandbox.io/s/aschild-props-ref-forwarding-3ysrdr?file=/src/App.js

Other libraries like Headless and Reakit have worked more smoothly

I'm curious on this point, I would imagine the same requirements apply for their polymorphic props as apply to asChild, i.e. they would require props and ref passed to custom components as well. Has your experience differed there?

[JodiWarren]

I'm curious on this point, I would imagine the same requirements apply for their polymorphic props as apply to asChild, i.e. they would require props and ref passed to custom components as well. Has your experience differed there?

Yes, maybe I just got lucky with the prop names, but they both worked out of the box. This is pretty close to how I used them in the POCs I made:

Headless UI:

<Menu.Button as={React.Fragment}>
  <Button some="props" for="customising">
    My button contents
  </Button>
</Menu.Button>

Reakit/Ariakit:

<MenuButton state={menu}>
  {props => (
    <Button some="props" for="customising" {...props}>
      My button contents
    </Button>
  )}
</MenuButton>

I know I'm spreading props there, but I can get away (for now) with spreading the props in the implementation, whereas it's a bit trickier to do in the action component receiving them.

[andy-hook]

I see, perhaps a coincidence then. I can't imagine their implementations can work differently as there's no way for a library to account for the lack of forwarding within a custom component afaik.

I quickly updated the example just to demo that:
https://codesandbox.io/s/aschild-props-ref-forwarding-3ysrdr?file=/src/App.js

And their docs on the matter
https://headlessui.com/react/menu#integrating-with-next-js

But either way I understand it's not very ergonomic, hopefully React can improve on these things in the future. In the case of your project / design system there are a lot of additional benefits to forwarding unknown props on a leaf component – more flexibility to consumers when handling events, easier to apply generic attributes in tests, interop with polymorphic props etc. It's worth considering to provide better composability overall.

Hope this helps 🙏