Tooltip: Position and delay

[martinkrulltott]

Here are three topics for the Tooltip component:

1. The fade in time is shorter than the fade out time, causing the previous tooltip to "stick" when the next tooltip is triggered. As seen in the video below:

tooltip-delay-2021-02-18_16.30.54.mp4

---

2. The tooltip is bound by the area of the parent, causing a list of items with tooltips to render the first item's tooltip below the item, even if position top is set. As seen in the video below:

tooltip-pos-2021-02-18_16.28.59.mp4

---

3. How can the tooltip be position based on the mouse position? Either having the tooltip follow the mouse across a triggerable element (Follow) or letting the tooltip render in a fixed place based on the position where the mouse first triggered it (Use first position)?
   red dot represent the mouse position, green arrow representing the tooltip target
   

[martinkrulltott]

ps. Maybe 1. is already covered by #230

[Birkbjo]

I agree, I think that would solve this.
2.: I would imagine this would be resolved if the fade out times was to be decreased, so potentially solved through #230 as well?

3.: The second use-case seems to actually be possible. See this codesandbox. The popper-ref is exposed to children, so we can use this to set a virtualElementRef. I tried to implement the Follow use-case as well, but as it's a ref, the state is not updated on mousemove.

I'm not sure the best way to support the follow-usecase. Maybe @HendrikThePendric has ideas? We could potentially change popperReference to be in state, and expose a setPopperReference to the render-props in Tooltip.

[martinkrulltott]

2. would still be an issue even with a smoother transition. The placement ties the tooltip to an item, so if it's rendered below the top item it's now actually "tied" to another item further down.

The example for 3. looks good 👍

[KaiVandivier]

(2) was a stylistic choice by me when I prevented tooltips from showing outside of their parent container - I thought it would be better to flip the tooltip to keep it inside the parent instead of scrolling the tooltip outside or hiding it. I think the choice makes more sense when you look at a taller reference component like in this demo: https://ui.dhis2.nu/demo/?path=/story/tooltip--hides-when-out-of-frame

[martinkrulltott]

In case where ´placement´ is used, I'd be surprised if the tooltip started displaying in other places but the one selected, except for of course because of the boundary of the browser window (rendering outside of the browser window doesn't make much sense). In my case specifically, the placement ties the tooltip to an item, since its in a list, so I suggest either rendering outside of the parent (respecting ´placement´) or providing a prop to toggle this behaviour.

[KaiVandivier]

Having the flipping be prop-configurable would probably be fine; the tradeoff is that if it's disabled, you will got some disembodied tooltips while the reference element is partially covered, which becomes increasingly weird with increasing reference element height (see the pics at the bottom).

Linking the tooltip position to the mouse position as mentioned above would improve the 'disembodied tooltip' situation, to be sure.

Before that happens though, can I try to clarify exactly the behavior you're expecting?

Seems like:

Reference element position	Popper position	Expected behavior	Current behavior
Fully visible in parent container	In its specified placement, intersects parent container	Popper shown in specified placement	Popper flipped to stay inside parent component
Clipped by parent container; partially visible (like in the pics below)	In its specified placement, outside of parent container	? (want to fill this in - without flipping, the popper would stick to the out-of-view top of the reference element and look 'disembodied')	Popper remains visible inside parent because flipped
Fully out of view	Out of view in default placement; still in view if it's flipped	Hide the popper	Hide the popper

Unflipped vs flipped

Unflipped (the mouse is over the inside rectangle)

...vs. Flipped

[martinkrulltott]

@cooper-joe ⬆️

[cooper-joe]

Based on the above, I think keeping the Flipped behaviour is best. @KaiVandivier's example of how the tooltips can become disembodied outside of the parent container for tall items shows this well. This is more problematic than the issue of items at the top of a parent container flipping.

If we implement cursor-following tooltips, which I think we should, then I think the flipping-outside-of-parent-bounds behaviour could be revised.

[martinkrulltott]

For 1., even though it will be solved by #230, I get the feeling this won't be resolved for 2.36. As an MVP for the issue described in this ticket, could we change the in and out times to match? Should just be a one-liner and would help solve the DV issue for 2.36.

[cooper-joe]

#230 is solved by dhis2/ui#511, which looks like it will be available for 2.36.

[KaiVandivier]

PR merged 👍