Stuff like this is making me worry we're not closing the loop on the abstraction all the way

I think my preference would be to haveHelpTooltip export a separateHelpTooltipTrigger component, so that in the future, people don't need to go rifling around for the right component to get the help tooltip wired up. We could even make it so thatHelpTooltip just exportsTooltipTrigger under a different name – but I think that co-locating everything you need to wire up aHelpTooltip in one file is really important

The tricky thing is that theHelpTooltipTrigger component already exported byHelpTooltip renders a button with an SVG icon:

which is currently instantiated in 16 places like this:

So my thought with usingTooltipTrigger here is that you can insert whatever elements you want to act as a trigger (like inAgentLatency we're using a span instead of a button). Looking at it again, it is clunky.

What do you think about renaming the existingHelpTooltipTrigger to something likeHelpTooltipIcon orHelpTooltipIconTrigger, so that we can export Radix'sTooltipTrigger asHelpTooltipTrigger like you suggested?

I think I like the renaming approach better. I'm not even fully sure about having a version of the trigger that has an icon pre-baked, but I don't think it's all that egregious, and I imagine it'd be pretty easy to change it down the line

🙏

Big fan of the more accessible selectors

I'm trying to get some clarity on this comment: was this meant more in the sense of "I'm not sure if it's a good idea to do this", or "I feel like this is a good idea, but I'm not 100% sure how to do it"?

A bit of both, but more the latter. I think whenever aHelpTooltipAction is clicked, we want to close the tooltip. By having the tooltip-closing logic built intoHelpTooltipAction by default, we could write handlers likeonClick={onUpdate} here + wherever else we want to execute a function when closing a tooltip.

Since Radix doesn't export a component like<Popover.Close />, it seems the only way to do this is with a state hook. Is it a good idea to make every tooltip a controlled component? I'm not sure

Yeah, looking at Radix's API docs, I don't see anything that gives direct access to the state that's being contained insidePopover.Root

I imagine that if we want to bake that behavior in, we'd basically need to make wrappers over all thePopover components, and then wire up our own custom context (on top of the one already used by Radix) to control the closing state. I don't think that's too bad, but I also feel like Radix could've easily given a way to trigger that behavior if they felt like it was a common enough usage pattern

Unless we have a bunch of other components wiring that behavior up already, I feel like we can leave things be and wait for more examples to emerge

I think 0 is probably too fast. what's the default here?

The default is 700 which feels very long.

Worth mentioning that theMUI popover, whichdeprecated/Popover uses, doesn't use any delay, and I don't think we've added any:

so I used a delay of 0 to keep consistency with our current UX

could we set it to like, 200? I feel like 0 is intense

No, 0 is exactly as intense as prod is rn:

I'm so used to 0 delay that 200 feels sluggish to me: