-
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
Bumping EUI to 71.0.0 #147142
Bumping EUI to 71.0.0 #147142
Conversation
- the styling is significantly different on EuiRangeLevels and any previous tweaks likely should not carry over - also these classes no longer exist and as such their selectors no longer apply
- now that the component is wrapped in `withEuiTheme`, unfortunately things are extremely messy - unfortunately converting EuiDualRange to a function component is not necesssarily the answer as these specific use cases then lose access to the `onResize` instance method + fix incorrect usage of `rangeRef` in `src/plugins/controls` - the rangeRef was never actually getting passed down and thus never actually calling `onResize` - also `onResize` needs an actual width number
… attribute was added in PR #6445
…e in the EuiText class name that required a snapshot update
…e in the EuiText class name that required a snapshots update. [ScatterPlots] Updated the grayboilder plate and ticks/grid/axis colors within the ML scatterplt matrix wizard to match the EUI darkest shade
@elasticmachine merge upstream |
…ui-71.0.0 Merging in latest code from EUI upgrade branch
...(depVarIsRuntimeField || jobTypeChanged || depVarNotIncluded | ||
? { includes: formToUse.includes } | ||
: {}), |
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.
jobTypeChanged
was removed here because it caused extra renders of the component that prevented the includedFields
table on the Regression job page not to be automatically populated when dependentVariable
was selected. This occurred because this condition was detecting a job change when there wasn't one.
Pinging @elastic/eui-design (EUI) |
Pinging @elastic/uptime (Team:uptime) |
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.
Asset management LGTM
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.
security changes LGTM!
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.
Deployment Management changes LGTM
@@ -18,6 +18,7 @@ import { | |||
EuiText, | |||
EuiToolTip, | |||
} from '@elastic/eui'; | |||
import type { _SingleRangeChangeEvent } from '@elastic/eui/src/components/form/range/types'; |
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.
Instead of _SingleRangeChangeEvent, would it be possible to use EuiRangeProps['onChange'], like in https://github.com/elastic/kibana/blob/56e45b19c57371599ca0e164bfec1b417f1aa91a/x-pack/plugins/maps/public/classes/sources/es_geo_grid_source/resolution_editor.tsx?
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.
Unfortunately not because of the syntax used. onSigmaChange
is using function onSigmaChange() {}
as opposed to const onSigmaChange = () => {}
, and cannot be typed to a function type (EuiRangeProps['onChange']
) the same way as const
s can (at least, I couldn't find a way to accomplish this in my google journeys - I'd love to be wrong on this, please tell me if you know of a way to do so!)
I also attempted to use Parameters<EuiRangeProps['onChange']>[0]
but unfortunately Typescript couldn't figure that out - I think possibly due to some bizarre combination of reaching into an interface for a key and that key being optional/potentially undefined.
Importing the event type directly was the easiest way I could figure out to update typings without changing your source code, but if you're okay with changing your syntax - sure, we can make that change :)
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.
Reviewed this locally, paying special attention to the sliders, and everything looks good! The new design works well. Left a few questions about some of the changes.
min={hasAvailableRange ? rangeSliderMin : undefined} | ||
max={hasAvailableRange ? rangeSliderMax : undefined} | ||
min={hasAvailableRange ? rangeSliderMin : 0} | ||
max={hasAvailableRange ? rangeSliderMax : 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 this by getting the range slider control into a no-data state, and it looks the same as it did before. 👌
@@ -26,9 +27,11 @@ import { rangeSliderReducers } from '../range_slider_reducers'; | |||
import { RangeSliderReduxState } from '../types'; | |||
import { RangeSliderStrings } from './range_slider_strings'; | |||
|
|||
export const RangeSliderPopover: FC = () => { | |||
// Unfortunately, wrapping EuiDualRange in `withEuiTheme` has created this annoying/verbose typing |
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.
Is there anything we can do on our side to get rid of these complex types? Maybe a forward ref? Or some other way of getting a handle on the class?
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.
Honestly? Without knowing exactly why you're calling the internal EuiDualRange
's internal onResize
class method... my recommendation is to not do that 😅 (which removes the need for the ref
entirely, and thus the ref typing shenanigans).
If we ever convert EuiRange
/EuiDualRange
to functional non-class components as a tech debt item, you'd lose access to this API entirely (it's not something we're deliberately exposing or documenting as a consumer API). I did create a regression test to ensure we continued exposing onResize
via ref, just for this specific Kibana usage of it, but honestly, we'd prefer y'all not reach for it at all, or figure out what problem it's solving and have us try to solve it in a less technically hacky way.
I don't have the context as to why that original call was added or what it's doing - but it's definitely a code smell that makes me think either this usage of it is trying to do things EuiDualRange is not meant to do, or is super custom and undoing things EuiDualRange does and then re-doing them later (also not great).
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.
If I remember correctly, this usage is due to us not being able to use EuiInputPopover
, but still wanting to have the popover to be tied to the width of the input. I can't exactly remember why we couldn't use EuiInputPopover
though.
I wonder if we would run into any regressions by removing that call entirely? @cqliu1, do you remember why we had to use EuiPopover
?
event: ChangeEvent<HTMLInputElement | HTMLSelectElement> | MouseEvent<HTMLButtonElement> | ||
event: | ||
| ChangeEvent<HTMLInputElement | HTMLSelectElement> | ||
| KeyboardEvent<HTMLInputElement> |
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.
What exactly changed here requiring the addition of the KeyboardEvent
type?
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.
A slightly younger and far more naive version of me was looking at the EuiRange types and was like, "keyboard users / keyboard events on the input are also a thing! Let me modify our event types to add that, surely there won't be that many Kibana usages for us to update, right?"
Narrator: There were that many Kibana usages.
So yeah, that change is squarely my fault. The type change didn't really have to happen and was just me going "hm this is probably nice to have" and not realizing it would affect so many downstream Kibana consumers 😭 On the plus side, 6f1dfd2 dried out statically copied types for multiple instances/usages, so for most cases (except this one, where I couldn't extend EuiRangeProps['onChange']
for whatever arcane Typescript reason - see an earlier comment about Parameters<>
), this was generally a very small net cleanup.
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.
Visualizations changes LGTM, I did a brief testing in Lens and agg based visualizations that use ranges and everything works as expected.
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.
Enterprise Search changes LGTM
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.
Checked out, tested locally, and both the AnomalyThresholdSlider
and the RiskScoreMapping
EuiRange
components are functioning as expected within Security Solution. Security Detections changes LGTM! 👍 Thanks @breehall! 🙂
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.
Security investigations review! LGTM!
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.
ML changes LGTM
@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.
awp-viz lgtm
- use a more generic version instead
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsESLint disabled in files
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @breehall |
[email protected] ⏩ [email protected]
71.0.0
EuiRange
andEuiDualRange
designs where thelevels
are now on top of the tracks (#6092)discuss
anddotInCircle
glyphs toEuiIcon
(#6434)article
glyph toEuiIcon
(#6437)EuiProvider
usage warnings to not rely on development mode. (#6451)Breaking changes
EuiDualRange
now explicitly requires bothmin
andmax
via props types, to matchEuiRange
(#6092)EuiRange
andEuiDualRange
'scompressed
size no longer impacts track or level sizes, but continues to compress tick and input sizes. (#6092)euiCollapsibleNav*
euiColorPicker*
euiContextMenu*
euiControlBar*
euiDataGrid*
(except for z-indices and cell padding sizes)euiDatePicker*
euiSuperDatePicker*
euiDragAndDrop*
euiEuiEmptyPrompt*
euiFilePicker*
euiRange*
euiHeaderLinks*
euiKeyPad*
euiMarkdownEditor*
euiResizable*
euiSelectable*
euiSideNav*
euiStep*
euiSuggest*
euiTable*
(except for color variables)euiTooltip*
euiButtonFontWeight
,euiButtonDefaultTransparency
, andeuiButtonMinWidth
useEuiTheme()
instead. (#6443)CSS-in-JS conversions
EuiRange
andEuiDualRange
to Emotion; Removed$euiRangeThumbRadius
(#6092)logicalStyles
utility that automatically converts all non-logical properties in astyle
object to their corresponding logical properties (#6426)logicalShorthandCSS
utility that automatically convertsmargin
,padding
, and other 4-sided shorthands to their corresponding logical properties (#6429)logicalBorderRadiusCSS
utility that automatically convertsborder-radius
to corresponding logical properties (#6429)