feat(tooltip): pinned tooltip with actions

[nickofthyme]

Summary

Adds sticky tooltip interaction whenever Tooltip.actions are defined. See demo story here.

Features:

• Right-click to stick tooltip
• Select series on stuck tooltip
• Disables stickiness for empty tooltips
• trigger stickiness from tooltip actions or flag
• trigger actions with selected series
• global click listener to dismiss pinned tooltip
• Clear pinned tooltip on resize, esc or outside click
• limit scroll height to 5 items
• scroll nearest elements into view

Chart types with context menu:

• cartesian charts story example
• partition charts - story example
• heatmap - story example
• flamegraph - story example

TODOs (moved to #1859)

• Configure what is passed back to user (heatmap & flame)
• Block tooltip render when brushing (xy)
• Define if we need a different prompt if no actions are available but you can pin the tooltip to show all series.

Screen.Recording.2022-08-20.at.04.24.33.PM.mp4

Testing in kibana

To test against this PR on kibana update the package.json to point to the tooltip-actions-dist branch.

// package.json
{
  "dependencies": {
    "@elastic/charts": "https://gitpkg.now.sh/nickofthyme/elastic-charts/packages/charts?tooltip-actions-dist"
  }
}

Then run bootstrap with --no-validate flag...

yarn kbn bootstrap --no-validate

See kibana example/testing/demo at elastic/kibana#141503

Details

Modifies the interactions redux state to add tooltip stuck/selection state and account for the stuck state and disable existing interactions like drag and click while stuck.

The esc option to cancel the brush interaction was added a while ago but was a little loose when adding and removing the keyboard event listeners.

I have noticed that some of the tooltip interactions are tightly coupled to the redux store/selectors. This might become problematic as we are adding event listeners within packages/charts/src/components/chart_container.tsx that may not be implemented inside the reducers. For example, we had a keyup listener that was added but the reducer that it triggers may not actually do any logic.

We should have a better way to communicate interactions to the component that does not require as much redundant checks or logic.

Scroll into view demo

Screen.Recording.2022-08-29.at.05.56.53.PM.mp4

This feature works by scrolling to the first highlighted tooltip value. Some improvements on this logic could be...

• Some type of collapsing on groups for charts with hierarchical structures to always show highlighted values.
• Collapse values in between until tooltip is pinned.
• Currently the order of tooltip items is arbitrary but if we change this to be nearest-first we could have a better interaction. Currently, the closest is not element is not always scrolled to view, as seen at the end of the recording above where the cursor is closest to the line point but the bar values is focused.
• Shuffle the items to allow showing all highlighted values. Might be a bad idea

Issues

fix #1857

Checklist

• The proper chart type label has been added (e.g. :xy, :partition)
• The proper feature labels have been added (e.g. :interactions, :axis)
• The :theme label has been added and the @elastic/eui-design team has been pinged when there are Theme API changes
• All related issues have been linked (i.e. closes #123, fixes #123)
• New public API exports have been added to packages/charts/src/index.ts
• Unit tests have been added or updated to match the most common scenarios
• The proper documentation and/or storybook story has been added or updated
• The code has been checked for cross-browser compatibility (Chrome, Firefox, Safari, Edge)
• Visual changes have been tested with all available themes including dark, light, eui-dark & eui-light

[monfera]

Nice work! It's a WIP so all these below may be on your list already:

There are some statefulness issues, for example:

• activating the tooltip, then, as the next step, trying to activate it elsewhere just clears the pinned tooltip
• even after clearing (right-click on another bar) it's not possible to pin the tooltip, it requires that the mouse first be moved, probably to populate x/y values (right-click DOM interactions also pass on coordinates, so I think there should be no requirement for a mousemove)
• activating the tooltip, then left-clicking on another bar (or pretty much anything else, except, apparently, the Esc key or another right-click tooltip activation attempt) doesn't clear the pinned tooltip

It'd feel odd to maintain the pinned status if the user clicks (eg. left-clicks) elsewhere. A click is a strong expression of intent, whether activating something else or cancelling a current modality. Our interaction design for this should be such that it's super easy to get out of the pinned mode. So, starting with "literally everything gets the user out of pinned mode" then remove hover from that list (I think only a subsequent hover should leave the tooltip pinned)

Wondering if the pinned tooltip needs the common ☒ button on the top of the tooltip as another means for cancellation. While also observing Fitts law (ie. the unpin hotspot can/should be larger than the visible ☒ or pin symbol)

(Maybe it's done already) It'd also be great to link to an interaction design document. The current way doesn't just pin the tooltip, it in effect establishes a strong, new modality that overrides everything. Worth comparing it to the more fleeting persistence of such tooltips in Tableau. In any case, it's worth making interaction design choices explicit, and supported with comparisons and arguments

Minor: I'd also rename the PR, because it's more of a pinned thing than a sticky one, and whether the "tooltip" has actions or not is secondary, so I'd just call it "pinned tooltip" or similar. "Sticky" also has the issue that its past participle is "stuck" and that has other connotations (unwanted behavior, like a stuck button)

[markov00]

Agree with Robert, this only partially is related to the tooltip, this is more a contextual menu than a sticky/pinned tooltip.

For the interaction/cancellation/clearing it should behave exactly as a right-click context menu in the browser: if you click elsewhere or in one item of the menu, the menu will disappear immediately

[nickofthyme]

buildkite update vrt

[markov00]

Everything looks good expect for the fact that the control+click on mac doesn't works as expected. It initially pins the tooltip but a subsequent mouse movement will unpin the tooltip.
control+click should follow the same behaviour of the secondary click on mac (usually the two finger click)

[nickofthyme]

Everything looks good expect for the fact that the control+click on mac doesn't works as expected. It initially pins the tooltip but a subsequent mouse movement will unpin the tooltip. control+click should follow the same behaviour of the secondary click on mac (usually the two finger click)

Good catch, fixed in 0367fed

[markov00]

Everything looks good to me, amazing work Nick!

All issues have been addressed