feat(xy): mutilayer time axis step 1

[monfera]

Summary

Adds a preview of the hierarchical time axis via a new multiaxis story, including the minor code update to realize the preexisting left-align specification for the horizontal axis ticks. Refactors and improves on a lot of the Cartesian axis related code

BREAKING CHANGE

• feat: removes the axis deduplication feature
• fix: showDuplicatedTicks now causes a duplication check on the actual axis tick label (possibly yielded by tickFormat rather than the more general labelFormat)

Details

• adds a hierarchical time axis story
• fix/feat: the small update to actually left-align the horizontal axis ticks
• BREAKING feat: removes the axis deduplication feature
• BREAKING fix: showDuplicatedTicks causes a duplication check on the actual axis tick label (possibly yielded by Axis.tickLabel rather than the more general tickFormat)
• fix: turned all [].sort() calls safe (some API inputs used to be modified in the past; also, brittle to future code changes)
• fix(test): makes certain array comparison tests use toIncludeSameMembers instead of toEqual so the test remain neutral about the order of array elements (not all arrays need to have a specific order)
• fix: axisTickLabel (populated by Axis.labelFormat) is now precomputed and used for bounding box calculation and wherever it's needed for the actual axis tick rendering, as the preexisting label (populated by Axis.tickFormat) was generic, used eg. for tooltip formatting
• test: custom font that's fairly usable in live storybook mode (font for a11y: Atkinson Hyperlegible)
• refactor: swathes of axis related code eg. 350 lines removed from axis_utils.ts alone, not counting the deletion of the axis dedupe fun (refactoring is guided by certain objectives such as clarity of data flow, performance, simple types, avoidance of special cases and bails, expressions instead of control structures, succinctness)

Issues

Step 1 toward #1310 and elastic/kibana#51227

Checklist

• The proper chart type label has been added (e.g. :xy, :partition)
• The proper feature labels have been added (e.g. :interactions, :axis)
• All related issues have been linked (i.e. closes #123, fixes #123)
• New public API exports have been added to packages/charts/src/index.ts
• Unit tests have been added or updated to match the most common scenarios
• The proper documentation and/or storybook story has been added or updated
• The code has been checked for cross-browser compatibility (Chrome, Firefox, Safari, Edge)
• Visual changes have been tested with all available themes including dark, light, eui-dark & eui-light

[monfera]

jenkins test this

[nickofthyme]

Code changes LGTM. Didn't have time yet to go through the axis diff in great detail.

I think we should have a replacement VRT for every test that was deleted before merging this PR.

[nickofthyme]

Not sure. I think that was just to handle someone passing () => '' to the tickFormat.

[nickofthyme]

Yeah I'm not sold early return is best either. I don't see any performance pros and cons. But some times the fall-through case is usefully to where you don't have to do something like...

const myFunc(value: any) {
  if (!value) return false;
  if (value % 2) return true;
  return false;
};

I know it is in the kibana style guide but I don't love it.

[markov00]

I've tested it locally and works great (with the various fixed to the tickFormatter/labelFormatter now the tooltip header works great)

I think is good to merge after solving the legit Nick's comments

[monfera]

@nickofthyme @markov00

I think we should have a replacement VRT for every test that was deleted

My thought as well, to lock in the outcomes of the logic incl. corner case handling whose unit tests were removed. It's critical to aim for an as high ratio of code coverage with VRT as possible, hopefully 100% over time, at least everything that ultimately influences what gets rendered statically or upon interaction

before merging this PR

Due to the high volume of code that's changed laboriously and non-automatically, merging this soon would avoid nasty merge conflicts, and the much more limited (merge conflict free) test updates could be an immediate follow-up. Besides the merge conflict angst, the PR contains a few fixes (and VRT's them) and added safety so the balance may be positive. An earlier merge brings up potential regressions sooner. My recent stint with refactoring PRs removed around a couple thousand runtime lines and changed another few thousands, and where there's change there's risk of regression, so being exposed to usage feedback earlier has some merit.

Whether you prefer merging sooner or you'd rather await VRT coverage, I'd like to get help from the two of you, as sometimes it's not immediately clear what a unit test meant to lock in, in terms of user intent to final results. As you have more elastic-charts experience with the Cartesians, and wrote the tests, it's also more efficient to go parallel on this, or at least walk me through this on a call so we gather what images can cover the unit tests that got disused for one reason or another

Also linking Marco's "one for the team" PR as it covers some of what went away in unit tests here

[nickofthyme]

@monfera sure that's understandable. I think we just need to add some some storybook tests to replicate some of the unit test setup.

[nickofthyme]

🎉 This PR is included in version 35.0.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀