Tooltip abstraction using Slot doesn't work with components

[DaniGuardiola]

I've created a Tooltip abstraction using Slot:

import React, { ReactElement } from "react";
import { Root, Trigger, Content } from "@radix-ui/react-tooltip";
import { Slot } from "@radix-ui/react-slot";

function Tooltip(p): ReactElement {

  return (
    <Root delayDuration={0}>
      <Trigger as={Slot}>{p.children}</Trigger>
      {p.content && (
        <Content
          sideOffset={8}
          side={p.side}
        >
          {p.content}
        </Content>
      )}
    </Root>
  );
}

When I use it like this, it works:

function Test () => (
  <Tooltip content="test tooltip content">
    <div className="w-[100px] h-[50px] border flex items-center justify-center text-body-lg">
      Hover me!
    </div>
  </Tooltip>
);

However, if I use a component instead, it doesn't show up on hover:

function TestTrigger({ content }: { content: string }) {
  return (
    <div className="w-[100px] h-[50px] border flex items-center justify-center text-body-lg">
      Hover me!
    </div>
  );
}

function Test () => (
  <Tooltip content="test tooltip content">
    <TestTrigger />
  </Tooltip>
);

What am I missing? Thanks in advance!

Note: all code has been simplified, so it might have typos and other minor mistakes. I'm hoping I'm missing something obvious that can be detected with this code. If not, I will create a codesandbox for a functional repro.

[benoitgrelard]

You need to React.forwardRef on your TestTrigger.

Without that, a ref cannot be attached to the actual DOM node so it cannot be measured, and thus the tooltip cannot be positioned.

Important to note also, the trigger should be an interactive element, most likely a button. If you make it a div like this, you are left with handling all the accessibility yourself.

[uriklar]

Hi! A follow up on this question.
From what I understand this means that any component that I want to support a tooltip will need to spread a props object on it?
I mean:

const MyComponent = forwardRef(
    (
        {
            some,
            stuff,
            ...props
        }: Props,
        ref: ForwardedRef<HTMLButtonElement>
    ) => {
    return <StyledSomething {...props} ...

That seems a bit too loose for a design system component. Is there maybe a type or something that specifies the exact props that the tooltip forwards? So I can support specifically for those in my component.
Hope that was clear, and thanks for the amazing work!

[benoitgrelard]

@uriklar,

That is correct yes.
If you wanted to see specifically which handlers are needed, you can take a look at the trigger's source code.
However, I would not recommend it because this is all an implementation detail really.

[uriklar]

Thanks @benoitgrelard. I was wondering if these forwarded props are represented by some typescript type I can use?
It might be overkill, but I could have a helper function that uses that type to make sure i'm destructuring the specific tooltip props and nothing else. I understand your point about this being implementation detail, but if it has a maintained type than it makes it more maintainable.

If I wasn't clear, I mean something like

import { TooltipForwardedProps } from 'radix-ui/react-tooltip';

function extractTooltipProps(props: TooltipForwardedProps & { [key: string]: any }): TooltipForwardedProps {
  const { ...destructure all forwarded props and only those };
}

const MyComponent = (props) => {
    const tooltipProps = extractTooltipProps(props);
    
    return <button {...tooltipProps} />

[benoitgrelard]

Ideally we would actually be able to make this work at the TS level, and it would error when you slot in your component using asChild. However, this isn't currently possible due to some limitation in TS. See #895 for a discussion regarding this.

However, what you suggest in terms of maintaining/exposing a type, could be a halfway solution that would already be a little bit helpful for some people.

Although, I'm not sure how we would treat this from a semver pov. What happens if we change some of the handling under the hood at some point for some primitive. Usually that would be just a patch for us, because publicly nothing changed because we assume prop spread. But now if we maintain and expose types, then we're basically saying every handler is a part of the public API which makes things a lot less flexible for us over time.

@andy-hook what are your thoughts on this?

[andy-hook]

But now if we maintain and expose types, then we're basically saying every handler is a part of the public API which makes things a lot less flexible for us over time.

That's my biggest concern with exposing such a utility, though I totally understand the need for something in lieu of an internal TS option. Forgetting to forward props / refs is a legit common issue which I wish was easier to guard against.

I'm less sold on need in DS component prop narrowing, imo keeping an open api at the DS level is the more flexible / scalable approach, but I understand every project has different requirements.