You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 24, 2024. It is now read-only.
I would like for ticksCount's default to be expanded from 3-7 to include at least 9, if not more.
Additional Context / Screenshots
We normally do not pass in a ticksCount, since we can have two y axes, and would like for carbon to automatically calculate 'nice' values. However, our consumers have noticed and complained that in some scenarios it results in values that aren't 'nice'. For example, in the image below, the left y-axis has spacings of 8, and the right y-axis has spacings of 33, neither of which are 'nice' values, even though (or because) it has maxed out at 7 tick counts.
However, if 9 were an available value for ticksCount, we would note that it would then be possible to achieve truly 'nice' values, with the left y-axis having a spacing of 5, and the right y-axis having a spacing of 20. Beyond that, we have no idea what potential values the axes may have, so we're also recommending that we allow the default to go beyond 9, in case there is a scenario in which a higher ticksCount could result in nicer tick values.
I'd note here that while it might be recommended that we manually pass in a ticksCount of 9, this is something we're actively trying to avoid because, again, we don't know what the axes ranges may be, and 9 may not be a good ticksCount in all scenarios for us, which is why we're leaving it up to terra.
Is our logic here correct? Is there anything we're missing? Please let me know, thanks!
After thinking over the weekend, I'm wondering why the logic didn't choose 4 for the ticksCount, half of the proposed 9 ticksCount, which would've resulted in the left y-axis having a spacing of 10 and the right y-axis having a spacing of 40, which also would've been 'nice' values. Odd?
@pc592 the default logic in terra-graphs for implementing the ticks is designed to determine an appropriate amount of ticks based on the size of the ranges in order to keep the axes aligned and keep the tick values aligned with the graph's grid. The number of ticks is simply based off the average combined ranges for the Y and Y2 axes.
There are too many scenarios and multiples that would need to be considered in attempt to provide what each application deems "appropriate" for the graphs they generate. This is why terra-graphs provides other avenues for applications to determine what values are displayed on the Y axes. Given that your application owns the data set, understands the data ranges and what values would be preferred on the graph, your application would be the better judge of what the tick values should be. In order to get the tick values you want, our suggestion is that you do not rely on the default and instead provide your own tickCount or array of tick values that would be ideal for your graphs.
Feature Request
Description
I would like for ticksCount's default to be expanded from 3-7 to include at least 9, if not more.
Additional Context / Screenshots
We normally do not pass in a ticksCount, since we can have two y axes, and would like for carbon to automatically calculate 'nice' values. However, our consumers have noticed and complained that in some scenarios it results in values that aren't 'nice'. For example, in the image below, the left y-axis has spacings of 8, and the right y-axis has spacings of 33, neither of which are 'nice' values, even though (or because) it has maxed out at 7 tick counts.

However, if 9 were an available value for ticksCount, we would note that it would then be possible to achieve truly 'nice' values, with the left y-axis having a spacing of 5, and the right y-axis having a spacing of 20. Beyond that, we have no idea what potential values the axes may have, so we're also recommending that we allow the default to go beyond 9, in case there is a scenario in which a higher ticksCount could result in nicer tick values.
I'd note here that while it might be recommended that we manually pass in a ticksCount of 9, this is something we're actively trying to avoid because, again, we don't know what the axes ranges may be, and 9 may not be a good ticksCount in all scenarios for us, which is why we're leaving it up to terra.
Is our logic here correct? Is there anything we're missing? Please let me know, thanks!
@ Mentions
@sdadn
The text was updated successfully, but these errors were encountered: