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

[Lens] Don't allow values outside of range for number of top values #78734

Merged
merged 10 commits into from
Oct 1, 2020

Conversation

mbondyra
Copy link
Contributor

Summary

Fixes #61780
It limits the user to only type values in the range. I also changed the range from [1,20] to [1,100] as it was one of the suggestions. It's open to discussion though.

@mbondyra mbondyra added release_note:fix Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.0.0 Feature:Lens v7.10.0 labels Sep 29, 2020
@mbondyra mbondyra requested a review from a team September 29, 2020 08:26
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app (Team:KibanaApp)

change range to 1-100
Copy link
Contributor

@dej611 dej611 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested the PR in Safari, Firefox and Chrome.
It is ok 👍 .

A minor improvement, to me, would be if the number input would also handle the empty string as transition value (ie 1 => 25) rather than fallback to 1.

Copy link
Contributor

@dej611 dej611 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the behaviour is somewhat logically correct here, but the fact that the chart does not render the MAX_NUMBER_OF_VALUES here instead of my out of bound 300 does not convince me 100%. What do you think?

I would expect in this case to not render 300 bars, rather 100 at least as the range input moves to that. But I'm open to alternative solutions.

top-values-range

@mbondyra
Copy link
Contributor Author

I can see both bad and good sides of changing the values to the border ones in case of outside of range (that's probably expected for some users) and not doing it (user that accidentally types something won't modify their data by mistake) – I don't have a strong opinion so I'll stick to yours :) Updated!

Copy link
Contributor

@wylieconlon wylieconlon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested the behavior and it mostly LGTM, just found one edge case.


type PropType<C> = C extends React.ComponentType<infer P> ? P : unknown;
// Add ticks to EuiRange component props
const FixedEuiRange = (EuiRange as unknown) as React.ComponentType<
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you submit a PR to Eui to fix this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now looking at this code, I think it should already be fixed so I'll just remove it.

onChange: (value: number) => void;
}) => {
const MIN_NUMBER_OF_VALUES = 1;
const MAX_NUMBER_OF_VALUES = 100;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with setting it 100 based on our "best practices" case, but we could also set it based on the MAX_BUCKETS ui setting. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of having it in the ui settings, but right now the set value for metrics:max_buckets is 2000. I checked in Visualize that we indeed allow terms of that many values, but the rendering is so slow (in my computer around a minute, if it doesn't stall completely) that it's completely unusable. And as it's easier to just use EuiRange to accidentally slide the value up than manually type it as we do in Visualize, I'd rather stick to maximum of 100 for lens. We could also add it as a separate setting in advanced settings if you think it's worth it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would go forward with the PR in its current state as it's an improvement over the behavior in the old version. Long term we can rethink this UI (maybe a slider without text input and a free input as an "advanced mode"?) - but IMHO that's out of scope for this PR.

aria-label={i18n.translate('xpack.lens.indexPattern.terms.size', {
defaultMessage: 'Number of values',
})}
/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found it confusing that I could be in an invalid state as long as I had focus, and the red highlighting would only appear once I blur the input:

Screen Shot 2020-09-29 at 3 05 41 PM

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I noticed that too, but this is the internal behaviour of EuiRange - even adding isInvalid prop with some conditions doesn't help - the condition 'is fired' on blur and not on change, so it won't help. I'll speak to eui team to see if they can do something about. For now, do you think it's a blocker to merge this one?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opening an issue for EUI is worth it, but it shouldn't block the PR IMHO

@flash1293
Copy link
Contributor

@elasticmachine merge upstream

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested in Chrome and Firefox and LGTM - the behavior seems predictable and understandable to me. Showing the invalid state on the input right away would be a nice touch but we can fix that later IMHO.

@mbondyra
Copy link
Contributor Author

mbondyra commented Oct 1, 2020

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

@kbn/optimizer bundle module count

id before after diff
lens 560 561 +1

async chunks size

id before after diff
lens 995.6KB 997.8KB +2.3KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Lens release_note:fix Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.10.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Lens] Allows outside of range size for terms
6 participants