While exploring the Tooltip functionality, I noticed that hoverTooltip consolidates several operations into a relatively large extension.
Due to the exclusivity of mouse hover, merging multiple tooltips at overlapping ranges into a tooltip host is feasible. However, this combination is closely tied to the events processed by hoverTooltip().
Could we consider introducing a simpler interface, like showTooltip, which accepts a list of tooltips, automatically merging them if overlaps occur, or even leaving the confirmation to users? This way, users can handle interactive events more freely.
Could you say a bit more about the use case you’re working with? What kind of tooltips are you creating that should be merged? And why doesn’t a system where you make them one tooltip that takes input from some custom facet work?
Could you say a bit more about the use case you’re working with?
We track a position with our extension, capturing events like mouse hover. Other extensions generate data from this position, feeding it to the showTooltip facet. While it works well, the issue is that DOM nodes are not docked in a single tooltip container. Even though hoverTooltip is aware of merging multiple tooltips into one host, we can’t reuse it.
What kind of tooltips are you creating that should be merged?
As precisely the set of tooltips that hoverTooltip() would pop up, given the singular input: hover.
And why doesn’t a system where you make them one tooltip that takes input from some custom facet work?
While it indeed works if the operation is simply hovering the mouse and popping up the tooltip, as the first answer explained, we are dealing with a position rather than a specific event.
I still don’t quite understand. There’s a single ‘active’ position at any time, and multiple extensions can be adding tooltips to that position? If so, it still seems like having them instead feed information into a custom facet, and having a single extension that creates a combined tooltip from that facet whenever it contains any values, should be straightforward.
Yes, this is exactly what I worked on today. This was a trade-off between implementation and design: If CodeMirror had already opened a showHoverTooltip similar interface, we could opt for simpler code where feeding tooltips would be sufficient (therefore, we wouldn’t have this discussion at all). However, I believe forcing every extension to prescribe, rather than describe, their view creator might be awkward in our use case.