[Bug]: Bar width needs to be scaled by the number of time periods #1554
Description
Name
Martin
Are you an IBM employee?
- [ ] Yes
What happened?
Not sure if this is a bug or just something that can be improved...
The problem is that for bar charts that use a time scale the bar width calculation doesn't really make sense if the bars are not distributed evenly:
return Math.min(options.bars.maxWidth, (chartWidth * spacingFactor) / numberOfDatapoints);At:
In the calculation, the chartWidth * spacingFactor is divided by the number of data points to determine how much space each bar needs. However, the number of data points cannot be used as a reliable divisor because the bars may not be evenly distributed across the time domain.
See this example:
The bar width is scaled with the assumption that the bars are distributed evenly. But because the bars are clustered at the start and end of the time domain, they overlap.
I'm making the assumption that the time scale will usually be applied for data that is mapped to evenly spaced time periods (e.g. per second, minute, hour, day, month, year, etc.). Given that, it would be better if the bar width would scale with the number of time periods between the min and max date on the domain. The time period size could be an option or automatically determined from the data (see GCD).
So in the example above the number of time periods is 12, while the number of data points is 5. If the bars were scaled by the number of time periods they would be thinner and fit nicely in the chart area without overlap (though maybe there needs to be a margin to account for the space around the edges).
This is my desired bar behaviour:
Hope this makes sense!
Version
@carbon/[email protected]
Data & options used
No response
Relevant log output
No response
Codesandbox example
https://codesandbox.io/s/epic-bassi-7ml64n?file=/src/index.js
What priority level would this be in your opinion?
P0