[Feature] Allow SplitLine's on top of progressed part of gauge chart

[alex-anderson-addepar]

What problem does this feature solve?

The gauge chart SplitLine appears below the progressed part of the chart. For example:

However, I'm trying to get the split lines to appear on top of the progressed section, for example:

In this example I did actually get my desired chart to render, but it required rendering two charts, one with a lower z-index which shows everything and another on top of that chart with just the splitlines shown. I suspect, however, that this would break some accessibility features and introduce some lag to our pages. It is also just a weird workaround which requires drawing multiple charts to get the functionality which really should be available in one.

I did find https://github.com/apache/echarts/issues/16262 which gave me the idea for drawing multiple charts. It's a different issue which isn't as simple as just needing one part of the chart drawn on top of another, but the work around is the same.

What does the proposed API look like?

There are two approaches. One focuses on the splitlines and the other fixes related issues as well.

The specific approach could be adding something to splitLines to draw it above the progressed part of the chart, something like:

{
  splitLine: {
    distance: -18,
    show: true,
    length: 18,
    lineStyle: {
      width: 4,
      color: '#FFF'
    }
    // new property
    drawAboveProgress: true,
  }
}

The more broad-reaching approach could be giving parts of the chart z-indices. It seems that some parts of some charts (i.e. the legend) do have the z property available, so perhaps this isn't a very novel idea at all. Perhaps it could be something like:

{
  type: 'gauge',
  z: 1,
  // ...
  splitLine: {
    z: 5,
    distance: -18,
    show: true,
    length: 18,
    lineStyle: {
      width: 4,
      color: '#FFF'
    }
  },
},

More broadly, we could add this to other components, or even just lineStyle and I suspect that this would solve a lot of related issues. Also, if z already means something slightly different (ie canvas z index), perhaps it would make sense to create a new property called drawOrder for this?

[helgasoft]

two gauges on top of each other usually solves similar problems - see #19971

[alex-anderson-addepar]

two gauges on top of each other usually solves similar problems - see #19971

@helgasoft This works and I've linked this workaround in my post, but wouldn't a better more wholistic solution be to allow changing draw order or z index on a component level? It seems like it would be both more performant and less hacky.

[helgasoft]

@alex-anderson-addepar - sure, adding a new feature is better. It just takes a lot of knowledge to build, and lot of time to be approved. So I focus on workarounds.