feat(brush): add multi axis brushing

[markov00]

Summary

This commit allows the consumer to configure the direction used by the brush tool from
<Settings brushAxis="x / y / both" /> .
By default, the direction is along the X-axis, but can be configured to go along the Y-axis or along both axes.
For the Y-axis values, we are returning an array of values, one for each Y-axis defined (this is determined by the groupId associated with different axis/series groups)

Along Y axis:

Along both axis, aka rectangular selection:

BREAKING CHANGE: The type used by the BrushEndListener is now changed to reflect this change. The BrushEndListener is changed to

type BrushEndListener = (brushArea: XYBrushArea) => void;

export interface GroupBrushExtent {
  groupId: GroupId;
  extent: [number, number];
}
export interface XYBrushArea {
  x?: [number, number];
  y?: Array<GroupBrushExtent>;
}

fix #587

Summarize your PR.

If it involves visual changes include a screenshot or gif.

Checklist

Delete any items that are not 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)
• This was checked for cross-browser compatibility, including a check against IE11
• Proper documentation or storybook story was added for features that require explanation or tutorials
• Unit tests were updated or added to match the most common scenarios

[codecov-io]

Codecov Report

Merging #625 into master will increase coverage by 0.57%.
The diff coverage is 84.84%.

@@            Coverage Diff             @@
##           master     #625      +/-   ##
==========================================
+ Coverage   66.44%   67.01%   +0.57%     
==========================================
  Files         240      252      +12     
  Lines        7012     7228     +216     
  Branches     1340     1328      -12     
==========================================
+ Hits         4659     4844     +185     
- Misses       2337     2367      +30     
- Partials       16       17       +1     

Impacted Files	Coverage Δ
src/chart_types/xy_chart/utils/specs.ts	100.00% <ø> (ø)
...t_types/xy_chart/state/selectors/get_brush_area.ts	85.71% <81.25%> (+21.00%)	⬆️
...es/xy_chart/state/selectors/on_brush_end_caller.ts	86.95% <84.48%> (-2.70%)	⬇️
src/scales/scale_band.ts	97.36% <100.00%> (ø)
src/scales/scale_continuous.ts	97.65% <100.00%> (ø)
src/specs/settings.tsx	90.90% <100.00%> (+0.28%)	⬆️
src/utils/commons.ts	100.00% <100.00%> (ø)
src/mocks/scale/index.ts	100.00% <0.00%> (ø)
src/mocks/utils.ts	88.88% <0.00%> (ø)
src/mocks/specs/index.ts	100.00% <0.00%> (ø)
... and 9 more

---

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 e9b09ce...7de8739. Read the comment docs.

[rshen91]

LGTM!! Tested locally in Chrome and Safari . The brush tool story is clear on both browsers and is easy to understand.

[nickofthyme]

Looks good, very nice enhancement. I just had two thoughts while playing around with it.

Thought 1

I noticed that you sort the values for the start and end regardless of which was actually the start. I don't think this should be the case if someone needs to know the order of which the action happened, left to right or right to left.

Thought 2

Could you add a minimum height and/or width to the selection overlay? If the user is brushing for any case they can see nothing but the cursor. Just a few pixels maybe.

[markov00]

@nickofthyme I've added the the minBrushDelta prop to <Settings /> to specify a minimum number of pixel to identify a brush area as valid 7de8739
I prefer to keep the brushed values in a sorted array [min, max], then having them as [first, last]
we can then change this behavior later.

[nickofthyme]

@markov00 That's fine for the sort order.

For the min delta, I don't see the min number behavior, It still allows me to make the line invisible. Am I missing something?

[monfera]

Disappearing area: users are box selecting during a continuous expression of intent, ie. holding down the mouse, dragging and seeing visual feedback, encountering a special case which shows zero area, which even corresponds to the current intent. The user keeps pressing the mouse button and is likely to move further if wanted. Also, click-hold-drag-release is appropriately done on low-risk interaction ie. there isn't much harm if the user releases the mouse and retries (if there are negative consequences, D&D is not a good activating mechanism to begin with).

Other libraries also have disappearing areas, eg. the lower Highcharts scatter or area, or the Plotly box select which is btw. an auto X/Y/box selector in this example.

It's possible to add eg. corner markers so that they fall outside the actual selected area, but then there are some mundane details to consider, eg. it can protrude outside the Cartesian area if a selection border coincides with an extreme (which is implementable but it may be a time cost/benefit tradeoff).

Besides the effort, code size and complexity, there are some advantages to keeping the visuals simple anyway:

• clean, simple, yet unambiguous feedback for the user
• small corner marks not interfering with the mouse cursor (which is why even the Plotly box markers are made to disappear

P.S. lasso and multi-box select are easier without corner markers
P.P.S. I added corner markers to active Kibana Canvas elements, but there it's a resize grab handle, so it was needed.

So it's a fine detail with some tradeoffs that I think wouldn't block this PR, OK done with the bike shedding for a while 🤣

[monfera]

Looks good! Nice touch: it's possible to select from the very edge of the shown Cartesian area even if 100% pixel accuracy can't be expected of users (Fitts law)

[nickofthyme]

The latest changes are exactly what I expected and look really good.

[markov00]

🎉 This PR is included in version 19.0.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀