Axis renders behind grid

[sergeykimaia]

Describe the bug VictoryAxis line render's behind it's grid

Victory version "victory": "^36.5.3",

Code Sandbox link https://codesandbox.io/s/basic-victory-example-forked-i14tcd?file=/index.js

To Reproduce Steps to reproduce the behavior:

1. Go to the stack overflow link and see the chart

Expected behavior grid should be behind the Axis line

Screenshots

Desktop (please complete the following information):

• OS: macOS 12.4 - Browser chrome
• Version 03.0.5060.114 (Official Build) (x86_64)

[IlanZ93]

Hi,

Use <VictoryAxis /> to customize the color of the Axis and the Grid, set the same color, and add a little opacity for the Grid and this solve your problem.

https://codesandbox.io/s/basic-victory-example-forked-hpz2ty?file=/index.js

[sergeykimaia]

@IlanZ93 thank you, your solution works.

may I ask, do you know if the issue I posted in this task is a bug or is it intentional?

[IlanZ93]

I am not working on this package so i can only make guess, but think this is a bug.

I thought its only occurs when first data = first axis tick but i tried with tickValues and still got the bug but on the Y axis this Time !

[Burnett2k]

Hi there, I'm looking into this issue and was able to reproduce on the latest version of Victory. Although it looks like there's a workaround, the defaults should look nice as well. I will update this thread if I can find a solution.

[Burnett2k]

The issue appears to be more complicated than I hoped, and no solution has been found yet. The crux of the issue is that each axis has it's own (group) which draws the axis and gridlines for itself.

example(simplified pseudo-html):

<svg>
  <g>
    <axis line>
    <grid lines>
  </g>
  <g>
    <axis line>
    <grid lines> // this always writes over the top of the first axis line
  </g>
</svg>

The two axes conflict with each-other because the last one to be drawn always puts a grid line on top of the opposite axis.

Since z-indexes cannot be use to set the order of svg elements, you can only rely on them to paint in the order they're written. That means if you swap one for the other, you just end up causing the issue on the opposite side of the axis. So, switching the paint order will not work without some kind of refactoring of how grids and axes are already drawn.

In some situations where the first tick is 0, we do actually detect this issue and remove 0 from ticks. This works well, but enhancing this logic would be very difficult as it would require taking into account both axes data, and we currently don't do so.

For now, we recommend if this is an issue to use the workaround above. We will consider looking into re-writing some of the svg painting logic to avoid this issue in the future.