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

[EuiButton][EuiButtonEmpty][EuiButtonIcon] Remove color="ghost" #7296

Merged
merged 9 commits into from
Oct 25, 2023

Conversation

cee-chen
Copy link
Member

@cee-chen cee-chen commented Oct 18, 2023

Summary

This PR removes color="ghost" only for EUI button components. It does not remove color="ghost" for EuiIcon, EuiText, or EuiLink.

This PR also closes #7287 (last component with .defaultProps). Removing the ghost logic allows us to correctly destructure default props in the original function params (see b7dc9b4).

Update paths

  • If the color="ghost" context is being used within EuiBottomBar or any other component that automatically sets a dark color mode, simply change the prop to color="text"
  • If not, create your own <EuiThemeProvider colorMode="dark"> wrapper around your button, and then change to color="text"

Downstream effects

This affects multiple usages in Kibana and other Elastic consumers. I went ahead and opened PRs with migrations to remove usages:

For 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

  • Browser QA
    • Checked in both light and dark modes
    • Checked in Chrome, Safari, Edge, and Firefox
      - [ ] Checked in mobile
      - [ ] Checked for accessibility including keyboard-only and screenreader modes
  • Docs site QA
  • Code quality checklist
  • Release checklist
    • A changelog entry exists and is marked appropriately.
    • If applicable, added the breaking change issue label (and filled out the breaking change checklist)
  • Designer checklist
    • Updated the Figma library counterpart

- 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
@github-actions
Copy link

github-actions bot commented Oct 18, 2023

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:

  • If this PR contains prop/API changes:
    • Search through Kibana for <EuiComponent usages (example search)
    • In the PR description or in a PR comment, include a count or list with the number of component usages in Kibana that will need to be updated (if that amount is "none", include that information as well)
  • If this PR contains CSS changes: N/A

@cee-chen cee-chen marked this pull request as ready for review October 18, 2023 22:28
@cee-chen cee-chen requested a review from a team as a code owner October 18, 2023 22:28
- appears to be because we're renaming it via destructure, doh
@kibanamachine
Copy link

Preview staging links for this PR:

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

History

@JasonStoltz JasonStoltz self-requested a review October 19, 2023 13:15
>
{isMobileSize ? 'Theme' : currentTheme.text}
</EuiButton>
<EuiThemeProvider colorMode="dark" wrapperProps={{ cloneElement: true }}>
Copy link
Member

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?

Copy link
Member Author

@cee-chen cee-chen Oct 19, 2023

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):

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!

Copy link
Member

@JasonStoltz JasonStoltz left a 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';
Copy link
Member

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?

Copy link
Member Author

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">
Copy link
Member

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?

Copy link
Member Author

@cee-chen cee-chen Oct 19, 2023

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 }}>
Copy link
Member

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?

Copy link
Member Author

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 😅

@cee-chen
Copy link
Member Author

cee-chen commented Oct 19, 2023

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.

@cee-chen
Copy link
Member Author

cee-chen commented Oct 25, 2023

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.

@cee-chen cee-chen removed the blocked label Oct 25, 2023
@cee-chen cee-chen merged commit c866299 into elastic:main Oct 25, 2023
10 checks passed
@cee-chen cee-chen deleted the button-ghost-props branch October 25, 2023 21:44
cee-chen added a commit to elastic/kibana that referenced this pull request Nov 3, 2023
`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))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Warning : "defaultProps" will be removed
4 participants