Voronoi stack

[stefvhuynh]

Fixes FormidableLabs/victory#619.
Requires FormidableLabs/victory-core#332.

Component from issue for testing:

render() {
    const chartProps = {
        containerComponent: <VictoryVoronoiContainer labels={(d) => d.y} />
        // containerComponent: <VictoryVoronoiContainer />
    }

    const areaProps = [
        {
            data: [
                { x: 1, y: 3 },
                { x: 2, y: 3 },
                { x: 3, y: 3 },
            ],
            // labelComponent: <VictoryTooltip />,
            // labels: (d) => d.y
        },
        {
            data: [
                { x: 1, y: 1 },
                { x: 2, y: 1 },
                { x: 3, y: 1 },
            ],
            // labelComponent: <VictoryTooltip />,
            // labels: (d) => d.y
        }
    ]

    return (
        <VictoryChart {...chartProps}>
            <VictoryStack>
                <VictoryArea {...areaProps[0]} />
                <VictoryArea {...areaProps[1]} />
            </VictoryStack>
        </VictoryChart>
    )
}

Toggle comments to ensure labels works in both cases.

[stefvhuynh]

There is an issue with the very last chart in the voronoi container demo. Hovering no longer highlights the bars. Chart in question:

[boygirl]

More work necessary. This implementation destroys voronoiBlacklist functionality

[f0rr0]

@boygirl not sure if this would be related but I observed that voronoi container has some unexpected behaviour https://codesandbox.io/s/4z6ww6w7m0

[boygirl]

Depends on FormidableLabs/victory-core#390

[boygirl]

@f0rr0 yes, that looks potentially related. The issue was that voronoi data was naive. None of the calculated data values were i.e. _x0, _y0 were being used when determining the voronoi. I think that might be causing the issue you're seeing as well, but I will double check before I release this change (probably tomorrow)