Victory Container events don't work with a non-standalone chart

[jamieparkinson]

The active state doesn't get 'switched on' consistently when using VictoryVoronoiContainer for a VictoryChart with standalone={false} like this: https://jsfiddle.net/pzkofefm/2/. It seems like it only registers when the cursor is hovering over the elements in the chart - an issue I never had when using the old VictoryVoronoi.

Have I missed something in terms of other props that need to be set?

[boygirl]

@jamieparkinson You're right, this is not operating as expected. I'll look into it today.

[chrisbolin]

hmm, I saw something similar to this while working on FormidableLabs/victory-chart#453 and trying/breaking things to experiment. I'll take a look, too

[chrisbolin]

it seems like it fails if you simply wrap the <VictoryChart> in an svg, regardless of what the standalone prop is

[chrisbolin]

Ahh, I think I found the problem @boygirl. When the containerComponent prop is added, standalone seems to be overridden: even with standalone=false VictoryChart still renders a wrapping svg, so you have two: one in user-land (that's why it was standalone=false) and one added by the container component.

[chrisbolin]

I added some logging to VictoryZoomContainer and can confirm that the container's defaultEvents eventHandlers (for target "parent") don't fire as they should...

[jamieparkinson]

@chrisbolin nice bug-hunting! I am working my way into the victory codebase so I can try to help with stuff like this myself 🙂

[chrisbolin]

This affects all "evented" containers (VictoryVoronoiContainer, VictoryBrushContainer, VictorySelectionContainer, and VictoryZoomContainer) so I updated the title

[jellyninjadev]

Any updates on this one? Still having issues on Victory Group Cursor wrapped with Svg

[boygirl]

This one is a wontfix. Evented containers only work with standalone={true}