Inconsistent/buggy yaxis ticks (too many or none)

[jsmartt]

Description

yaxis ticks have had some significant changes in version 3.46 and 3.47, and the behavior of the newer versions is worse IMO.

In version 3.45, for my data sets and chart size of 250px height, I was consistently seeing about 5 yaxis ticks.
In version 3.46, with the same data and height, I was suddenly seeing double the ticks. 10 ticks is too many for a 250px height chart, and looks significantly worse IMO.
In version 3.47+, I'm still seeing about 10 ticks, but have noticed that with some data sets, there are zero ticks when there definitely should be some.

I know I can set the number of number of yaxis ticks with the tickAmount option, but it would be nice if the default behavior was sufficient. Also, for some strange reason, starting in 3.47.0, if I set the tickAmount, it can result in the first yaxis tick being negative, even though all the values are positive. Again, I'd like the min and max to be automatic/dynamic, not hardcoded to zero.

This could be 3 separate issues, but I think they could all be related to the same function(s).

Steps to Reproduce

1. Create a few simple line charts with any data you choose. My series values are typically between 5 and 10,000.
2. Compare the yaxis behavior between apexcharts versions 3.45.2, 3.46.0, 3.47.0, and latest.

Expected Behavior

The number and spacing of yaxis ticks should not clutter the chart, and should be somewhat consistent over time.

Actual Behavior

The number and spacing of yaxis ticks has changed significantly in versions 3.46 and 3.47, and the ticks have cluttered the chart in these later versions. Sometimes the ticks are missing altogether.

Screenshots

This matrix demonstrates how things have changed over time, and the bug in 3.47+ where there are no ticks:

Reproduction Link

Chart with missing ticks: https://codepen.io/jsmartt/pen/OJeOLwr

Comparisons between version 3.45.2 and latest with the same data: https://codepen.io/jsmartt/pen/poXdzxJ & https://codepen.io/jsmartt/pen/wvLPvrK

Chart with yaxis min set to negative number, even though all values are positive: https://codepen.io/jsmartt/pen/mdZqdqZ (broke in 3.47.0)

[rosco54]

Hi Jared,

Yes, there was a major rewrite of the auto (nice) scaling routine starting at 3.46.0 to address a number of issues including:

1. ensuring that multiple Y axis scales and labeling would all align to each other and to the horizontal grid when shown.
2. use tick increments (default stepSize) that are even multiples of 10 etc. (eg ,1, 2, 5, 10)
3. the default number of ticks was changed back to 10, after a short time at 5 prior to 3.46.0, but the algorithm will try to eliminate extra superfluous ticks if possible to maximize the chart's visual resolution.
4. the priorities of the various yaxis options, min, max, tickAmount, stepSize and forceNiceScale changed (broadly to have that weighting, with some exceptions).
5. the number of scale ticks is reduced as the chart SVG height shrinks (window resizing, etc) to avoid overcrowding.

When you only get the X axis and one other tick, as in your Series 1: 3.47.0 plot, it's usually because the algorithm computed a nice number of ticks to display but could not reduce that number nicely to fit the SVG height. If you change the example to chart.height: 270 you'll see the full set of ticks that were computed and you can see that it will become overcrowded if the SVG goes much smaller (265 appears to be the threshold in this case).

In each of your examples, setting the following will improve or fix the chart.

yaxis:
{
  forceNiceScale: true
},

Or, in your last example where you explicitly set tickAmount to a value (try some values other than 5 to see the effect):

yaxis:
{
  tickAmount: 5,
  forceNiceScale: true
},

forceNiceScale: true changes the axis scaling, ticks, etc in different ways depending on which other options are configured and thus mandatory to observe. Sometimes it will have no effect at all.

Note: the algorithm always tries to produce a nice axis scaling and the rewrite simply reused this, otherwise redundant, option to give users control over some possible variations.

[rosco54]

PS to my previous comment:

As of 3.47.0 yaxis.forceNiceScale: true causes the default initial number of ticks to be selected based on the SVG size, overriding the default of 10. For an SVG height of 250px this should result in an initial default of 6, which may be reduced further as described in my previous comment.

[rosco54]

PPS:

To keep you up-to-date and hopefully avoid you making unnecessary changes to your charts, I'm currently reworking the code in an attempt to accommodate the issues raised. If it can be done without adversely affecting existing charts, it will be submitted as a PR for consideration by the maintainers. If this doesn't work you have the solution above.

[jsmartt]

Thanks for the detailed response and quick turn around on this @rosco54! I'll give it a shot next week

[jsmartt]

yaxis.forceNiceScale: true definitely looks promising so far. It did address all my concerns on the codepen examples. Thanks again!

[rosco54]

That's great, however for clarity, the code changes that have now been accepted and will appear in the next release should work for your examples with or without ```forceNiceScale: true```.

…

On Tue, 20 Aug 2024, 1:09 am Jared Smartt, ***@***.***> wrote: yaxis.forceNiceScale: true definitely looks promising so far. It did address all my concerns on the codepen examples. Thanks again! — Reply to this email directly, view it on GitHub <#4632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGBUF44C3DHFTBH2JO5WMTDZSIDDTAVCNFSM6AAAAABMMU6FAGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWHAYTGMZUGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>