-
Notifications
You must be signed in to change notification settings - Fork 841
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
[EuiButton][EuiButtonEmpty][EuiButtonIcon] Remove color="ghost"
#7296
Conversation
- This will fix our props tables and inferred `defaultProps` logic
- now throwing type errors from EuiButton ghost removal - worth noting: this component is slated for deprecation in 1 month
This PR contains breaking changes. The opener of this pull request is asked to perform the following due diligence steps below, to assist EUI in our next Kibana upgrade:
|
- has no actual user-facing effect
- appears to be because we're renaming it via destructure, doh
Preview staging links for this PR:
|
💚 Build Succeeded
History
|
> | ||
{isMobileSize ? 'Theme' : currentTheme.text} | ||
</EuiButton> | ||
<EuiThemeProvider colorMode="dark" wrapperProps={{ cloneElement: true }}> |
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.
Looking at the Update Paths, this would be a case where:
if not, create your own wrapper around your button, and then change to color="text"
So in this context, we want to maintain the "ghost" coloring of this button, which is why we wrap it in a theme provider set explicitly to "dark".
This essentially makes the button permanently and independently exist in a "dark mode" context, isolating it from any other dark/light mode changes in any higher-level theme contexts.
Does that all track? I'm just trying to understand.
Does this only impact color mode? Meaning, if other theme changes are set in a higher-level theme context, would they still flow through to this button?
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.
This essentially makes the button permanently and independently exist in a "dark mode" context, isolating it from any other dark/light mode changes in any higher-level theme contexts.
Yeah, your understanding is totally correct!
Does this only impact color mode? Meaning, if other theme changes are set in a higher-level theme context, would they still flow through to this button?
Yes! Child theme providers will always inherit from their most recent parent. So you could even do something like this:
<EuiProvider>
// App
<EuiThemeProvider modify={{ size: { base: 20 } }}>
// Some modified content
<EuiThemeProvider colorMode="dark">
// Will inherit *both* the size override and dark color mode settings
</EuiThemeProvider>
</EuiThemeProvider>
</EuiProvider>
Here's the source code for that behavior if you're curious (we grab the parent React context and then merge in any modifications and then pass that down as the new context):
eui/src/services/theme/provider.tsx
Lines 74 to 77 in b1c8582
const parentSystem = useContext(EuiSystemContext); | |
const parentModifications = useContext(EuiModificationsContext); | |
const parentColorMode = useContext(EuiColorModeContext); | |
const parentTheme = useContext(EuiThemeContext); |
All the credit to Greg for creating that component with flexibility and future-proof-ness in mind!
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.
@cee-chen These code changes all look good to me. I dropped a couple of clarifying questions but otherwise this LGTM.
{...rest} | ||
/> | ||
); | ||
}; | ||
|
||
EuiButton.displayName = 'EuiButton'; |
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 take it this was just redundant?
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, unless we're using forwardRef or have some other reason for renaming components (e.g. HOCs and other shenanigans), we don't need to manually set a displayName
.
@@ -16,7 +16,7 @@ export default () => { | |||
<EuiSpacer size="xl" /> | |||
<EuiSpacer size="xl" /> | |||
<EuiBottomBar position="sticky" bottom={10}> | |||
<EuiText color="ghost" textAlign="center"> |
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.
Wouldn't we need color="text" here to maintain the ghost coloring?
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.
EuiText defaults to color="text"
! So we don't need to specify a color (unlike buttons which default to color="primary"
)
Edit to add: And EuiBottomBar
already sets a dark mode context by default
|
||
export default () => { | ||
return ( | ||
<> | ||
<div css={{ overflow: 'auto', blockSize: 200 }}> |
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.
This is just a bonus fix in addition to the ghost changes?
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.
Yes! It's in its own separate commit as well 76577f7. I usually add a note to my PR descriptions recommending that folks follow along with changes by commit as I tend to throw in a lot of misc cleanup items in (but I try really hard to keep my git history clean so that optional cleanup items are separate from actual features or main functionality).
TBH I noticed a while back that the demo was broken on prod and was too lazy to fix it then, this PR was a good excuse 😅
FYI, I'm going to hold off on merging this into main until all the linked Kibana PRs are merged in. There's no point releasing with this until then; it'll just stall our next Kibana upgrade because this change will end up breaking/causing a bunch of type issues that we need team approvals/QA on in any case. |
There's just 1 PR remaining in Kibana to remove usages, so I'm going to go ahead and merge this now to get it into next week's release. Worst comes to worst, I'll roll the open PR into our next Kibana upgrade which then justifies asking the KibanaOps team for an admin merge. |
`v89.1.0`⏩`v90.0.0` The majority of changes in this PR come from: - **EuiContextMenu** being converted to Emotion (elastic/eui#7312). If your usage of `EuiContextMenu` was significantly affected, we recommend pulling down this PR and QAing it locally. - `defaultProps` being removed from some very widespread components, particularly **EuiButton**, in anticipation of React's upcoming deprecation. (elastic/eui@b7dc9b4) **NOTE**: This only affected Enzyme snapshots, and did not affect production behavior. [Commits](https://github.com/elastic/kibana/pull/170179/commits) have been broken up by component changes as well as types of changes. --- ## [`90.0.0`](https://github.com/elastic/eui/tree/v90.0.0) - Updated the `eventColor` prop on `EuiCommentEvent` to apply the color to the entire comment header. ([#7288](elastic/eui#7288)) - Updated `EuiBasicTable` and `EuiInMemoryTable` to support a new controlled selection API: `selection.selected` ([#7321](elastic/eui#7321)) **Bug fixes** - Fixed controlled `EuiFieldNumbers` not correctly updating native validity state ([#7291](elastic/eui#7291)) - Fixed `EuiListGroupItem` to pass `style` props to the wrapping `<li>` element alongside `className` and `css`. All other props will be passed to the underlying content. ([#7298](elastic/eui#7298)) - Fixed `EuiListGroupItem`'s non-transitioned transform on hover/focus ([#7298](elastic/eui#7298)) - Fixed `EuiDataGrid`s with `gridStyle.stripes` sometimes showing buggy row striping after being sorted ([#7301](elastic/eui#7301)) - Fixed `EuiDataGrid`'s `gridStyle.rowClasses` API to not conflict with `gridStyle.stripes` if dynamically updated ([#7301](elastic/eui#7301)) - Fixed `EuiDataGrid`'s `gridStyle.rowClasses` API to support multiple space-separated classes ([#7301](elastic/eui#7301)) - Fixed `EuiInputPopover` not calling `onPanelResize` callback prop ([#7305](elastic/eui#7305)) - Fixed `EuiDualRange` incorrectly positioning highlights when rendered with `showInput="inputWithPopover"` ([#7305](elastic/eui#7305)) - Fixed `EuiTabs` incorrectly wrapping text when it should instead either scroll or truncate ([#7309](elastic/eui#7309)) - `EuiContextMenu` now renders text colors correctly when used within an `EuiBottomBar` ([#7312](elastic/eui#7312)) - Fixed the width of `EuiSuperDatePicker`'s Absolute date picker ([#7313](elastic/eui#7313)) - Fixed `EuiDataGrid` cells visually cutting off overflowing content a little too quickly ([#7320](elastic/eui#7320)) **Deprecations** - Deprecated `EuiBasicTable` and `EuiInMemoryTable`'s ref `setSelection` API. Use the new `selection.selected` API instead. ([#7321](elastic/eui#7321)) **Breaking changes** - Removed `EuiPageTemplate_Deprecated`, `EuiPageSideBar_Deprecated`, and `EuiPageContent*_Deprecated` ([#7265](elastic/eui#7265)) - Removed the `ghost` color option from `EuiButton`, `EuiButtonEmpty`, and `EuiButtonIcon`. Use an `<EuiThemeProvider colorMode="dark">` wrapper and `color="text"` instead. ([#7296](elastic/eui#7296)) **Dependency updates** - Updated `refractor` to v3.6.0 ([#7127](elastic/eui#7127)) - Updated `rehype-raw` to v5.1.0 ([#7127](elastic/eui#7127)) - Updated `vfile` to v4.2.1 ([#7127](elastic/eui#7127)) **Accessibility** - `EuiContextMenu` now correctly respects reduced motion preferences ([#7312](elastic/eui#7312)) - `EuiAccordion`s no longer attempt to focus child content when the accordion is externally opened via `forceState`, but will continue to focus expanded content when users click the toggle button. ([#7314](elastic/eui#7314)) **CSS-in-JS conversions** - Converted `EuiContextMenu`, `EuiContextMenuPanel`, and `EuiContextMenuItem` to Emotion; Removed `$euiContextMenuWidth` ([#7312](elastic/eui#7312))
Summary
This PR removes
color="ghost"
only for EUI button components. It does not removecolor="ghost"
forEuiIcon
,EuiText
, orEuiLink
.This PR also closes #7287 (last component with
.defaultProps
). Removing theghost
logic allows us to correctly destructure default props in the original function params (see b7dc9b4).Update paths
color="ghost"
context is being used withinEuiBottomBar
or any other component that automatically sets a dark color mode, simply change the prop tocolor="text"
<EuiThemeProvider colorMode="dark">
wrapper around your button, and then change tocolor="text"
Downstream effects
This affects multiple usages in Kibana and other Elastic consumers. I went ahead and opened PRs with migrations to remove usages:
color="ghost"
button cleanup kibana#169304ghost
colors fromEuiBottomBar
kibana#169309color="ghost"
buttons kibana#169305color="ghost"
onEuiBottomBar
children kibana#169307ghost
colors fromEuiBottomBar
kibana#169308ghost
colors fromEuiBottomBar
kibana#169310color="ghost"
buttons kibana#169312color="ghost"
where unnecessary kibana#169313For more context, see #6820
QA
No UI should have changed or visually regressed as a result of this PR. Docs changes to QA:
General checklist
- [ ] Checked in mobile- [ ] Checked for accessibility including keyboard-only and screenreader modes@default
if default values are missing) and playground toggles- [ ] Checked Code Sandbox works for any docs examplesAdded orupdated jest and cypress tests