Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EuiDualRange] Bug when passing big integers as tick values #4765

Closed
miukimiu opened this issue Apr 28, 2021 · 5 comments · Fixed by #4781
Closed

[EuiDualRange] Bug when passing big integers as tick values #4765

miukimiu opened this issue Apr 28, 2021 · 5 comments · Fixed by #4781
Assignees
Labels

Comments

@miukimiu
Copy link
Contributor

As part of the review on elastic/kibana#96791, I noticed that the EuiDualRange doesn't fill 100% of the width when big integers tick values are passed.

I run some tests here: https://codesandbox.io/s/holy-rgb-rgjg2?file=/index.js.

Screenshot 2021-04-28 at 14 34 49

As we can see:

  • The top timeslider gets the full width and the one from the bottom doesn't.
  • The one from the top has tick values like value: 20. The one from the bottom has tick values like value: 1619049600000.

It seems that the component doesn't handle properly bigger integers.

@thompsongl
Copy link
Contributor

Same issue as #4109, although I'm not sure how to account for the fact that the labels here are the same size and the margin problem still occurs.

@thompsongl
Copy link
Contributor

I'm not sure how to account for the fact that the labels here are the same size and the margin problem still occurs

Looks like the tick value is always used to determine extra spacing, not the label (if provided)

@thompsongl
Copy link
Contributor

It'll be easy to solve the problem shown above where the labels are the same; the two ranges will render the same size with a few small changes.

I think the best strategy is to remove the added margin and instead shift the label slightly left, like so:

Screen Shot 2021-04-28 at 2 28 10 PM

It's slightly more likely that label overlaps will occur. The larger problem is attempting to prevent overlap in the first place, which I'm starting to believe we simply can't do with the level of tick customization we allow.

For instance,

Screen Shot 2021-04-28 at 2 30 47 PM

No shifting of the label in the available space will resolve the overlap. The only real solution is to rotate labels. This could be a configuration option we add, but it still requires placing the burden of label overlap prevention on the consumer.

@thompsongl
Copy link
Contributor

What do you think @miukimiu, Align the labels with the end of the range, or reserve some space and have the labels extend beyond the range?

Screen Shot 2021-04-29 at 12 08 31 PM

Screen Shot 2021-04-29 at 12 09 29 PM

@miukimiu
Copy link
Contributor Author

miukimiu commented May 4, 2021

@thompsongl, I think is better to reserve some space and have labels extended beyond the range. This way we gain more space to avoid overlaps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants