-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Lens] Don't allow values outside of range for number of top values #78734
Conversation
Pinging @elastic/kibana-app (Team:KibanaApp) |
x-pack/plugins/lens/public/indexpattern_datasource/operations/definitions/terms.test.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/lens/public/indexpattern_datasource/operations/definitions/terms.test.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/lens/public/indexpattern_datasource/operations/definitions/terms.tsx
Outdated
Show resolved
Hide resolved
change range to 1-100
There was a problem hiding this 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.
x-pack/plugins/lens/public/indexpattern_datasource/operations/definitions/terms.tsx
Outdated
Show resolved
Hide resolved
3c5563a
to
a768f96
Compare
There was a problem hiding this 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.
...gins/lens/public/indexpattern_datasource/operations/definitions/terms/values_range_input.tsx
Outdated
Show resolved
Hide resolved
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! |
There was a problem hiding this 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< |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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', | ||
})} | ||
/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
@elasticmachine merge upstream |
There was a problem hiding this 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.
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]@kbn/optimizer bundle module count
async chunks size
History
To update your PR or re-run it, just comment with: |
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.