WIP: Refactor the tooltip positioning logic

[envex]

What does this implement/fix?

See if we can move away from positioning the tooltip based a bunch of math around the data and SVG points.

I think we should be able to use data attributes to get all the data we need to render and position the tooltips. We already have it available when we render the chart elements, why not just use that and skip all the getXPosition and getAlteredX functions we have for each chart.

This should make adding tooltips to new charts way easier.

The basic idea is that the TooltipWrapper is always watching mouse movements for a chart. If it hovers over an element with a set of data-attributes specific to rendering charts x position, y position and activeIndex we will render a tooltip for that specific point/index.

Storybook link

https://6062ad4a2d14cd0021539c1b-oanoehqfpg.chromatic.com/?path=/story/polaris-viz-playground-tooltip-o-rama--tooltip-orama

Before merging

• Check your changes on a variety of browsers and devices.

• Update the Changelog's Unreleased section with your changes.

• Update relevant documentation, tests, and Storybook.

• Make sure you're exporting any new shared Components, Types and Utilities from the top level index file of the package

[envex]

This story won't stay around, it's just for testing/development

[envex]

This is where the first part of the logic starts.

We watch mousemove and if we're hovering over an element that provides us (at least) the activeIndex, we will render the tooltip.

Most likely the element will also provide x and y, but at minimum the activeIndex will render a tooltip for that index.

After we have x/y positions, we check if the tooltip needs to be repositioned.

[envex]

This is the second part of the logic.

Once we have the initial x/y of the tooltip, we need to check if the position needs to be changed.

This can either be:

• The tooltip will render outside the bounds of the browser window.
• If the tooltip was repositioned back into the window, we check to see if it would be covering the data point and we try to reposition it again.

This logic is located in the useRepositonTooltip() hook.

The reason we do this here and not in TooltipWrapper is because we need access to the height & width of the tooltip. We don't have access to the actual sizing of the tooltip until we've rendered this component.

[envex]

For charts that always update their tooltip position (LineChart, DonutChart) the only repositioning we do it to keep the tooltip inside the bounds of the browser window and away from covering the cursor.

[envex]

For charts that don't update their position, we likely pass a seriesBounds prop.

This prop is a set of x, y, height and width values that we use to position the tooltip around.

For example, in a BarChart, if the tooltip has been repositioned into the seriesBounds we will try and reposition the tooltip to the left of the seriesBounds so that the tooltip does not cover the bars.

[envex]

This is how we trigger the tooltip for a LineChart.

We render a rect for each data point which acts as the hover zone. These rects are rendered as red boxes with blue outlines below.

Each rect contains the data for it's activeIndex as well as the expected x/y for the tooltip.

When using a mouse, the x/y values here are ignored because the tooltip follows the cursor, but are used when using the Tab key to tab through the active points.