Fix the issue of labels in centre will overlap when alignLabels switc…#1702
Conversation
|
@eugene-korobko @SlicedSilver just curious if there are any plans to merge/check, we have noticed some labels overlapping when applying to align labels option, bit annoying. |
| recalculateOverlapping(top, 1, this._size.height, rendererOptions); | ||
| // move the last top to the first bottom to prevent overlapping between the items in top and bottom | ||
| if (top.length && bottom.length) { | ||
| bottom.splice(0, 0, top.splice(0, 1)[0]); |
There was a problem hiding this comment.
I would prefer an implementation which isn't performing splice operations on two arrays. It should be more efficient to rather pass the item from the top array (as a reference without a splice) into the recalculateOverlapping function as a parameter and have the recalculateOverlapping function know how to handle this extra parameter. This might add more complexity.
Or alternatively. Earlier in the current function, we could create the top array, and then sort it. Then create the bottom array and push the desired item into that, and then sort the bottom array.
// split into two parts
const top = views.filter((view: IPriceAxisView) => view.coordinate() <= center);
const bottom = views.filter((view: IPriceAxisView) => view.coordinate() > center);
// sort top from center to top
top.sort((l: IPriceAxisView, r: IPriceAxisView) => r.coordinate() - l.coordinate());
if (top.length && bottom.length) {
// add the last top to the first bottom to prevent overlapping between the items in top and bottom.
bottom.push(top[0]);
}
bottom.sort((l: IPriceAxisView, r: IPriceAxisView) => l.coordinate() - r.coordinate());There was a problem hiding this comment.
Well, as I remember we already had such string before. There is a risk it brokes the desired behavior on some cases
Type of PR: bugfix
PR checklist:
Overview of change:
In the library, it splits all the labels into top and bottom parts (based on the center coordinate), then recalculates the fixed coordinates for both parts. The issue occurs when calculating the bottom part, as it doesn't consider the coordinate of the last label from the top part, which causes some of the first items in the bottom part to overlap with the last items in the top part.
What has been changed in this PR is that the last item from the top part is moved to the bottom part. This way, when calculating the coordinates for the first item in the bottom part, it checks the last top item and adds the label's height if there is an overlap.
Is there anything you'd like reviewers to focus on?