Tooltip on Trigger

[PhilGarb]

Hi everyone,

I have a problem when using the Tooltip together with the Collapsible Trigger. I am styling the trigger based on data-state="open" to signal the open state to the user. When wrapping the Trigger in a custom Tooltip component, as described here: Radix Docs, the data-state attribute is overwritten by the Tooltips data-state.

I think a Tooltip should not really interfere in this way. I have tried to remove the Slot, but then I have two buttons both with their own data-state. This does however interfere with styling since in this case I have to change my styling to accommodate the deeper nesting.

I think the root cause is that all state is represented by only one attribute data-state and no way to distinguish states of different elements. Is there any way to make this work? Please let me know if you need a reproduction.

[benoitgrelard]

You are 100% correct, this is a clash because they both use data-state attribute. Few people have encountered this so far as it's an edge case when combining 2 primitives which happen to have state. This is a tricky problem to solve correctly.

The easy solution is to namespace the state attributes but that would be a huge restriction on DX for all of the most common use cases.

We'll need to think about this a lot more I think. In the meantime if you have some ideas/suggestions feel free to let us know!

[benoitgrelard]

That's good to know. That is something we will probably have to think about more, as we add more and more components.

[PhilGarb]

I have maybe found another option. There is the option to match only part of the data attributes when they are space separated. So something like: data-state="tooltip-open collapsibile-open" could be matched in css selectively with [data-state~="tooltip-open"] or [data-state~="collapsible-open"] The ~= is the important part here. This way a combination of data-state attributes could be done by prefixing and then telling the consumer to match them selectively.

[benoitgrelard]

Yeah but that's still prefixing, only the value rather than the key, still not great for DX…

[BrianHung]

Wouldn't mind prefixing on key, e.g. data-tooltip-state and data-dropdown-state. I prefer this over having nested buttons when I want to compose radix components together (tooltip and dropdown below).

<button data-state="closed">
  <button type="button" id="radix-:ri:" aria-haspopup="menu" data-state="closed" class="flex items-center justify-center w-12 h-12 hover:bg-black border-transparent hover:border-gray-200 focus:bg-sky-500 focus:outline-none state-open:bg-sky-500" tabindex="-1" data-orientation="horizontal" data-radix-collection-item="">
  </button>
</button>

[benoitgrelard]

Nested buttons is invalid anyway so that's out of the question really.

[jjenzz]

Is there any way to make this work?

@PhilGarb As you have realised, you can control all of our components to work around these sorts of issues in the meantime.

export default function App() {
  const [open, setOpen] = React.useState<boolean>();

  return (
    <Collapsible.Root open={open} onOpenChange={setOpen}>
      <Tooltip.Root>
        <Tooltip.Trigger
          as={Collapsible.Button}
          className={open ? 'open' : 'closed'} // or use `data-collapsible-state` if that's preferred :)
        >
          Open
        </Tooltip.Trigger>
        <Tooltip.Content>Tooltip</Tooltip.Content>
      </Tooltip.Root>
      <Collapsible.Content>Content</Collapsible.Content>
    </Collapsible.Root>
  );
}

https://codesandbox.io/s/adoring-grass-xtukv?file=/src/App.tsx

@benoitgrelard This has made me realise though that I had to do as={Collapsible.Button} so that the data-state is maintained from Tooltip.Trigger here. I found that a bit confusing. I initially expected that if I was telling a component to be something else, then the as component internal props would take precedence so I tried this at first:

export default function App() {
  const [open, setOpen] = React.useState<boolean>();

  return (
    <Collapsible.Root open={open} onOpenChange={setOpen}>
      <Tooltip.Root>
-        <Tooltip.Trigger
+        <Collapsible.Button
-          as={Collapsible.Button}
+          as={Tooltip.Trigger}
          className={open ? 'open' : 'closed'}
        >
          Open
-         </Tooltip.Trigger>
+        </Collapsible.Button>
        <Tooltip.Content>Tooltip</Tooltip.Content>
      </Tooltip.Root>
      <Collapsible.Content>Content</Collapsible.Content>
    </Collapsible.Root>
  );
}

Something to investigate perhaps?

[benoitgrelard]

Hmmm, yeah perhaps. I agree I would expect everything to kinda work the same whichever the order I compose them.

[jjenzz]

They can't work the same whichever way they're composed. One will always override the clashing props but I expected the as component would be the one that overrides (so data-state would be from Tooltip.Trigger if as={Tooltip.Trigger}) but that wasn't the case 🤔

[benoitgrelard]

Yeah that’s what I meant. Obviously here there’s a clash so one would always win. But yes I would expect that to change as well.

[jjenzz]

One to add to the list of DX improvements, it really confused me 😅

[giladv]

So i also encountered this issue. cannot combine a toggle with a tooltip.
i might be stating the obvious but why using a custom data-state attr instead of className?
a className can contain multiple classes, AND css selectors are designed to target just a single or multiple of the classes.

am i missing something?

a resulting element could look like:

<button class="radix-tooltip-open radix-toggle-on">..</button>

it fixes everything, the DX is far better than having to manage the state and it's a far more standard way of doing things IMO.

[MaxMusing]

+1 for @lucastobrazil's suggestion, this is something our team's been wanting too. We commonly need to compose multiple Radix components which leads to clashing data-states.

[lucastobrazil]

@benoitgrelard should I create an issue for this one?

[benoitgrelard]

We already have one #602

[lucastobrazil]

I'm not sure that actually relates to the topic here?

[benoitgrelard]

How so? This is about the issue of data-state clashes when composing multiple primitives. Isn't this what is being discussed in this discussion?

[hipstersmoothie]

I'm having the similar issue with Popover + Tooltip.

To get the Popover + Tooltip to work I has to use as="div" to get the events to bubble correctly. With asChild it doesn't work because of the component structure. The direct child is the Tooltip and not the TooltipTrigger so I think that's why that doesn't work.

const MixerButton = () => (
  <Tooltip>
    <TooltipTrigger asChild>
      <IconButton aria-label="Update dimensions">
        <MixerHorizontalIcon />
      </IconButton>
    </TooltipTrigger>
    <TooltipContent sideOffset={5}>Add to library</TooltipContent>
  </Tooltip>
);

const PopoverDemo = () => (
  <Popover>
    <PopoverTrigger as="div">
      <MixerButton />
    </PopoverTrigger>
    <PopoverContent sideOffset={5}>
      <Tooltip>
        <TooltipTrigger>here</TooltipTrigger>
        <TooltipContent sideOffset={5}>Testing</TooltipContent>
      </Tooltip>
    </PopoverContent>
  </Popover>
);

If I restructure the markup to the following:

   <Tooltip>
      <PopoverTrigger asChild>
        <TooltipTrigger asChild>
          <IconButton aria-label="Update dimensions">
            <MixerHorizontalIcon />
          </IconButton>
        </TooltipTrigger>
      </PopoverTrigger>
      <TooltipContent sideOffset={5}>Add to library</TooltipContent>
    </Tooltip>

It works (I.e the tooltip and popover both work) but then that means I can't use an API like the example given in the docs

 <Tooltip content="Tooltip content">
    <button>Tooltip trigger</button>
  </Tooltip>

So to get it to work I'd have to change my components API to match Radix's exactly. The as prop does what I want, but I'm nervous that it's been marked as deprecated but seem to be the solution here.

[benoitgrelard]

Hi @hipstersmoothie,

I don't think your issue is the same as the one discussed here (specifically clash of data-state).
In your case I believe your issue is that if you want to close over the MixerButton implementation you need to make sure it's public API behaves like a button, that means forwarding props and ref to it.

Here's a quick updated sandbox showing it working together nicely:
https://codesandbox.io/s/tooltip-popover-kyddq?file=/src/App.js

[billylittlefield]

I ran into this same issue when using a custom wrapper around Tooltip and trying to make that the child of a Dropdown.Trigger. This answer helped, and I changed my API so my custom tooltip now looks something like this...

export const CompanyTooltip = React.forwardRef(
    (
        {
            children,
            content,
            ...restOfProps
        }: {
            children: React.ReactNode;
            content: React.ReactNode;
        },
        ref: React.Ref<HTMLButtonElement>
    ) => {
        return (
            <RadixTooltip.Root>
                <RadixTooltip.Trigger asChild ref={ref} {...restOfProps}>
                    {children}
                </RadixTooltip.Trigger>
                <RadixTooltip.Portal>
                    <RadixTooltip.Content>
                        {content}
                    </RadixTooltip.Content>
                </RadixTooltip.Portal>
            </RadixTooltip.Root>
        );
    }
);

Now, when using this component inside a <Dropdown.Trigger asChild />, the dropdown trigger's props are correctly passed along.

While this issue (required ref/props-forwarding) is separate from this discussion's OP issue (data-attr clashing), the latter still comes into play here. For instance, in @benoitgrelard 's linked codesandbox when the tooltip is open, the data-state shows "closed" for the ButtonWithTooltip nested in a popover, but "delayed-open" for the standalone ButtonWithTooltip, because the Popover data-attrs win. This makes sense, and doesn't seem to actually affect the desired behavior, but wanted to call it out. I believe everything's still fine from an a11y perspective, because I see the aria-describedby being applied in both cases

Anyway, thanks for the useful discussion in this thread! I've been enjoying learning the Radix toolkit & seeing the active community.

[tarngerine]

I ran into this with Toolbar ToggleItems/Buttons, solution was to add a span around the trigger to prevent it creating two nested button OR mangling data-state

<Tooltip.Trigger asChild>
  <span>
    {children}
  </span>
</Tooltip.Trigger>

[jackbuscombe]

Thank u based god 🙏

[asfires]

Thanks so much for sharing this! I had this exact issue but this totally works and fixed it. In my case I had to add the asChild prop to my TooltipTrigger component and wrap my {item.key} in a span.

<TooltipProvider delayDuration={550}>
  <Tooltip>
    <FormLabel className="font-normal">
      <TooltipTrigger asChild>
        <span>{item.key}</span>
      </TooltipTrigger>
      <TooltipContent className="max-w-md">
        <p>{item.description}</p>
      </TooltipContent>
    </FormLabel>
  </Tooltip>
</TooltipProvider>

[Natan4Securitas]

Thanks, this worked for me too

[emlai]

This breaks accessibility, since the aria-describedby now gets added to the span instead of the focusable trigger element. So the tooltip doesn't get announced by screen readers.

[WilliamIPark]

Has any progress been made on resolving the data-state clash?

[dcastil]

Just chiming in with a solution I settled on when using multiple Radix components on the same trigger, like a tooltip and a dropdown menu on the same button.

My use case is that I have custom design system components like MyDropdownMenu and MyTooltip which both use Radix under the hood. That means that both will attach the trigger props to their children like the ref for the trigger, resulting in MyDropdownMenu passing those props onto MyTooltip instead of the intended Button.

// Problem
function MyButtonWithTooltipAndDropdown() {
    return (
        // ↓ MyDropdownMenu passes Radix props onto MyTooltip instead of intended Button
        <MyDropdownMenu>
            <MyTooltip>
                <Button>Click me!</Button>
            </MyTooltip>
        </MyDropdownMenu>
    )
}

The problem here is that MyTooltip already uses the ref and its rest properties for the tooltip content and therefore can't pass those down to the Button. The MyDropdownMenu component needs to "skip" the MyTooltip component and attach the props on the child of MyTooltip instead.

For this I created a ForwardPropsToChild component which does exactly that: It passes its own props to the child of its child.

import { Slot } from '@radix-ui/react-slot'
import { cloneElement, forwardRef } from 'react'

interface ForwardPropsToChildProps {
    children: React.ReactElement<{ children: React.ReactNode }>
}

export const ForwardPropsToChild = forwardRef<HTMLElement, ForwardPropsToChildProps>(
    function ForwardPropsToChild({ children, ...props }, ref) {
        return cloneElement(
            children,
            undefined,
            // Slot used so that callbacks, className, style, etc. are composed together instead of replaced.
            <Slot ref={ref} {...props}>
                {children.props.children}
            </Slot>,
        )
    },
)

This then can be used like the following code snippet to forward props to the intended component.

// Solution
function MyButtonWithTooltipAndDropdown() {
    return (
        // ↓ MyDropdownMenu passes Radix props onto ForwardPropsToChild
        <MyDropdownMenu>
            {/* ↓ ForwardPropsToChild forwards Radix props to Button */}
            <ForwardPropsToChild>
                <MyTooltip>
                    <Button>Click me!</Button>
                </MyTooltip>
            </ForwardPropsToChild>
        </MyDropdownMenu>
    )
}

I think it would be nicer to be able to get the props with a children function from Radix to pass the children props to another element in a more straight forward and explicit way. But so far the ForwardPropsToChild component is the least ugly solution I could come up with to mitigate the current issue.

Side note: This doesn't solve the issue with clashing states like data-state, but works well for cases where inserting another node in between elements makes layouting difficult.

[nklhtv]

To avoid collisions, data-state attributes can be scoped by id passed as a prop, e.g. by using React's useId() hook.
This behavior could be implemented as opt-in, so that its not a breaking change. If the primitive component receives no id prop then the state-open data attr will be used, otherwise state-${id}-open data attr will be used.

[Raepheles]

Is there still no progress on this? I wanted to have tooltip for toggle component and I was faced with the same problem. Toggle's "data-state" property doesn't update therefor classes based on data-state don't apply.

<TooltipProvider>
  <Tooltip>
    <TooltipTrigger asChild>
       <Toggle pressed={pressed} onPressedChange={setPressed}>
         <FontItalicIcon />
       </Toggle>
    </TooltipTrigger>
    <TooltipContent>
      <p>Tooltip</p>
    </TooltipContent>
  </Tooltip>
</TooltipProvider>