yMax / yMin does not work anymore without explicit boundaries

[jastax]

Hey,

I used to split the chart in 3 colored zones.

annotations: {
              first: {
                ...
                type: "box",
                yMin: 30,
              ..
              },
              second: {
                ...
                type: "box",
                yMax: 30,
                yMin: 1,
              ..
              },
              third: {
                ...
                type: "box",
                yMax: 1,
              ..
              },
....
}

But now it does not color the graph correctly anymore, unless I add yMax in the first box and yMin in the third box. Those values are dynamic though and I don't want to add boundaries.

Any advice?

Thanks!

[stockiNail]

@jastax I made a mistake in the sample. I'm still checking

[stockiNail]

@jastax it's not clear what you are expecting, therefore I have tried to create a sample to understand if the following is what you need:

If it's correct, try changing the yMin/yMax configuration, as following:

annotations: {
  first: {
    ...
    type: "box",
    yMax: 30,
    ...
  },
  second: {
    ...
    type: "box",
    yMax: 30,
    yMin: 1,
    ...
  },
  third: {
    ...
    type: "box",
    yMin: 1,
    ...
  },
....
}

Currently the defaults are calculating the yMin/yMax values based on chart area dimensions. but if the yMax is missing, the defaults is chartArea.bottom and if yMin is missing, the defaults if chartArea.top.

This could be misleading because, if the scale is defined with reverse: false (default), yMax is using the minim value of y scale (at chartArea.bottom) and for yMin viceversa (at chartArea.top).

The above proposal is a workaround. Probably the default calculation should take care about the reverse options of the scale.

[kurkle]

Probably the default calculation should take care about the reverse options of the scale.

I disagree, because there could be any number of options in a scale that affects how values are interpreted. But we should improve the documentation. I think min/max are considered to be relative to the top/left origin of the coordinate system.

[kurkle]

@jastax what do you mean by "anymore", what version were you using before?

[stockiNail]

. I think min/max are considered to be relative to the top/left origin of the coordinate system.

uhm... I'm not 100% with you. In my opinion, y/xMin or y/xMax are values of the scale (in fact they are calculating using the scale and not the chart area) and not a relative point starting from top/left of chart area.

[stockiNail]

@jastax what do you mean by "anymore", what version were you using before?

@kurkle let's wait for @jastax feedback but I think meant the plugin for chartjs v2.

See here how it was calculated:

chartjs-plugin-annotation/src/types/box.js

Lines 37 to 45 in 7ef33a9

	if (yScale) {
	min = helpers.isValid(options.yMin) ? options.yMin : yScale.getValueForPixel(chartArea.bottom);
	max = helpers.isValid(options.yMax) ? options.yMax : yScale.getValueForPixel(chartArea.top);
	model.ranges[options.yScaleID] = {
	min: Math.min(min, max),
	max: Math.max(min, max)
	};
	}

As you can see, it used chart area to calculate the value of scale at chart area top/bottom and use the value to calculate teh coordinates in the chart (and not how it is now where we are using directly the chart area dimensions).

[stockiNail]

because there could be any number of options in a scale that affects how values are interpreted.

I have to admit that I don't understand it. the reverse options is only changing the order on the scales to represent the datasets, whatever to be the type of the data.

Testing the reverse options, we could maintain the x/yMin and x/yMax options coherent with the data configuration of the user.
The reverse options will decide which is the minimum or maximum value on the scale to use as default when x/yMin and x/yMax options are undefined.

[jastax]

Hello,

thank you very much for your answers.
I was using 1.0.2 with Chart Js 3.5.1 (I think) before

Changing the annotations order does indeed change the way it's painted, but it's still not correct.

The image in which you can find green is the one with explicit yMin/yMax boundaries and the way it should be painted (also the gray area would not be visible and the red would be smaller).

The other two are with one yMin/yMax missing in two of the scales - both feature the same values, just the order has changed (as you suggested above)

[stockiNail]

@jastax thank you very much.

For your information, there is a PR #655 under evaluation which should solve this issue.

Could you create a codepen in order to be able to reproduce the above behaviors?

[jastax]

That's great news, thanks.

I won't be able to do it in the next few days but will try to create one after that.