fix(ticks): fill in additional ticks for histogram

[emmacunningham]

Summary

This PR introduces a fix for the issue where, in histogram mode, the intermediary ticks for a time scale were not being rendered.

The issue stemmed from how the ticks were being extended in histogram mode. Previously, we were just extending the ticks by 1 tick adding the scale's minInterval to the last computed tick. However, in cases where the interval between ticks was smaller than the scale's minInterval, this would mean that while the last tick would be correct, there would be missing intermediary ticks between the last computed tick and the final added tick. Now, we computed the distance between the ticks and add additional ticks with that interval until reaching the extended histogram domain end.

Before fix (note the missing ticks for the last bar):

After fix:

And additional test has been added to simulate the situation visible in the Storybook example and have also cleaned up the tests a bit to be easier to follow.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

- [ ] Any consumer-facing exports were added to src/index.ts (and stories only import from ../src except for test data & storybook)
- [ ] Proper documentation or storybook story was added for features that require explanation or tutorials

• This was checked for cross-browser compatibility, including a check against IE11
• Unit tests were updated or added to match the most common scenarios
• Each commit follows the convention

[codecov-io]

Codecov Report

Merging #251 into master will increase coverage by 0.17%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #251      +/-   ##
==========================================
+ Coverage   97.76%   97.93%   +0.17%     
==========================================
  Files          36       36              
  Lines        2641     2910     +269     
  Branches      590      710     +120     
==========================================
+ Hits         2582     2850     +268     
+ Misses         52       51       -1     
- Partials        7        9       +2

Impacted Files	Coverage Δ
src/lib/axes/axis_utils.ts	100% <100%> (ø)	⬆️
src/lib/series/specs.ts	100% <0%> (ø)	⬆️
src/lib/axes/canvas_text_bbox_calculator.ts	100% <0%> (ø)	⬆️
src/lib/utils/commons.ts	100% <0%> (ø)	⬆️
src/lib/series/rendering.ts	98.06% <0%> (+0.15%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fc6640d...5d33811. Read the comment docs.

[nickofthyme]

LGTM, tested and confirmed fix locally.

[nickofthyme]

I think giving the type for HOF is a little redundant given the array should have the type, also destructuring. Just a thought, no big deal.

Suggested change

	const histogramTickLabels = histogramAxisPositions.map((tick: AxisTick) => tick.label);
	const histogramTickLabels = histogramAxisPositions.map(({ label }) => label);

[emmacunningham]

I added the destructuring but kept the type annotation 5d33811

This is maybe something we will want to discuss more as a whole team, but in these kinds of cases, I prefer to see the type (even though it is not strictly necessary) because it helps me directly see the type of thing I'm working with without having to reference the array being mapped over; the explicitness isn't just for checking purposes but also reasoning purposes. Yes, it takes like milliseconds to check the type of the array and then infer the type of the function parameter, but making the type explicit frees up my working memory so that I don't have to do that inference myself. It's a small marginal benefit to be sure, but I'm not sure there's any disadvantage to having the type annotation here, so I'd take the small marginal benefit when I can.

Maybe this is something we can discuss in one of our upcoming syncs with @markov00?

[markov00]

Changes LGTM!