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

[EuiSuperDatePicker] Convert form control styles to Emotion #7904

Merged
merged 11 commits into from
Jul 23, 2024

Conversation

cee-chen
Copy link
Member

@cee-chen cee-chen commented Jul 22, 2024

Summary

This PR converts EuiSuperDatePicker's form control UI to Emotion. It does not convert any of EuiSuperDatePicker's popover styles to Emotion (for ease of review - plus to help separate some extra groundwork with EuiDatePicker's variables).

QA

https://eui.elastic.co/pr_7904/#/templates/super-date-picker should look the same as production with the following permutations:

  • States
    • When focused (click the Last 30 minutes text then click between ~30 minutes ago and now)
    • When invalid (click the Last 30 minutes text, then ~30 minutes ago, then change to minutes from now)
    • When in "needs update" mode (click the Last 30 minutes text, then ~30 minutes ago, then change to seconds ago from now)
    • When disabled (use Storybook for this and manually type in true to the isDisabled control)
  • Widths
    • When in restricted width mode (600px wide)
    • When in full width mode
    • When in auto width mode
    • When compressed

General checklist

  • Browser QA
    • Checked in both light and dark modes
    • Checked in mobile
    • Checked in Chrome, Safari, Edge, and Firefox
    • Checked for accessibility including keyboard-only and screenreader modes
  • Docs site QA - N/A
  • Code quality checklist
    - [ ] Added or updated jest and cypress tests
  • 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 - N/A
Emotion checklist

General

  • Output CSS matches the previous CSS (works as expected in all browsers)
  • Rendered className(s) read as expected in snapshots and browsers
  • ~[ ] Checked component playground ~

Unit tests

  • shouldRenderCustomStyles() test was added and passes with parent component and any nested childProps (e.g. tooltipProps)
  • Convert Enzyme tests to RTL

Sass/Emotion conversion process

  • Converted all global Sass vars/mixins to JS (e.g. $euiSize to euiTheme.size.base)
  • Removed or converted component-specific Sass vars/mixins to exported JS versions
  • Listed var/mixin removals in changelog
  • [ ] Ran yarn compile-scss to update var/mixin JSON files
  • [ ] Simplified calc() to mathWithUnits if possible (if mixing different unit types, this may not be possible)
  • [ ] Added an @warn deprecation message within the global_styling/mixins/{component}.scss file
  • [ ] Removed component from src/components/index.scss - Not yet
  • [ ] Deleted any src/amsterdam/overrides/{component}.scss files (styles within should have been converted to the baseline Emotion styles)

CSS tech debt

  • Wrapped all animations or transitions in euiCanAnimate
  • Used gap property to add margin between items if using flex
  • Converted side specific padding, margin, and position to -inline and -block logical properties (check inline styles as well as CSS)

DOM Cleanup

  • Did NOT remove any block/element classNames (e.g. euiComponent, euiComponent__child)
  • SEARCH KIBANA FIRST: Deleted any modifier classNames or maps if not being used in Kibana.

Kibana due diligence

  • Pre-emptively check how your conversion will impact the next Kibana upgrade. This entails searching/grepping through Kibana (excluding **/target, **/*.snap, **/*.storyshot for less noise) for eui{Component} (case sensitive) to find:
  • Any test/query selectors that will need to be updated - None
  • Any Sass or CSS that will need to be updated, particularly if a component Sass var was deleted - None
  • Any direct className usages that will need to be refactored (e.g. someone calling the euiBadge class on a div instead of simply using the EuiBadge component) - None
  • Search Kibana's codebase for {euiComponent}- (case sensitive) to check for usage of modifier classes - None for EuiSuperDatePicker, 2 for EuiDatePopoverButton
    • [ ] If usage exists, consider converting to a data attribute so that consumers still have something to hook into

Extras/nice-to-have

  • Reduced specificity where possible (usually by reducing nesting and class name chaining)
  • [ ] Documentation pass:
  • [ ] Check for issues in the backlog that could be a quick fix for that component
  • [ ] Optional component/code cleanup: consider splitting up the component into multiple children if it's overly verbose or difficult to reason about

- some shenanigans rquired because of existing render fn
- `noUpdateButton` requires a few per-width-type tweaks to get this working as before in prod, due to changed CSS delcaration order

- `isAutoRefreshOnly` is not correctly responding to width prop on prod, this fixes that
- flatten CSS where possible (in the case of `.euiFormControlLayout__childrenWrapper`'s border-radius it is sadly not possible)

- un-DRY prettyFormat CSS for now, DRY out with popover buttons later

- `!important` on `.euiSuperDatePicker__rangeInput` required to offset the CSS added by `fullWidth: true` on the form control layout
+ simplify `.euiDatePopoverButton` to inherit from the form wrapper instead of reusing the static variable
- use flex for compressed height instead of static form variables

- keep modifier classes for Kibana usage
- [opinionated cleanup/change] set background colors on the layout wrapper div instead of the button where possible

- reuse the CSS variable and form Emotion mixins where possible as well
@cee-chen cee-chen force-pushed the emotion/super-date-picker-1 branch from 426d8cb to 8146a82 Compare July 22, 2024 23:01
@cee-chen cee-chen marked this pull request as ready for review July 22, 2024 23:03
@cee-chen cee-chen requested a review from a team as a code owner July 22, 2024 23:03
component.setProps({ isPaused: true, refreshInterval: 0 });
jest.advanceTimersByTime(10);
await instanceRefresh.asyncInterval!.__pendingFn;
await jest.runAllTicks();
Copy link
Member Author

@cee-chen cee-chen Jul 22, 2024

Choose a reason for hiding this comment

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

@mgadewoll Your Jest upgrade PR allowed me to use this new handy util!! 🎉

@cee-chen cee-chen force-pushed the emotion/super-date-picker-1 branch from 8146a82 to 3abb05a Compare July 23, 2024 00:50
@cee-chen cee-chen force-pushed the emotion/super-date-picker-1 branch from 3abb05a to 1583a79 Compare July 23, 2024 00:50
@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

History

Copy link
Contributor

@mgadewoll mgadewoll left a comment

Choose a reason for hiding this comment

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

I left two small comments for clarification purposes on changes but apart from that the changes look good to me!


widths: {
restricted: css`
${logicalCSS('width', restrictedWidth)}
Copy link
Contributor

@mgadewoll mgadewoll Jul 23, 2024

Choose a reason for hiding this comment

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

Just for clarification: I noticed there is a tiny change in width here now, that I assume is expected? I see that previously the EuiSuperDatePicker had a restricted width of 606px and now 600px which seems more sensible.

Screen.Recording.2024-07-23.at.14.22.37.mov

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 I think the math was off with the previous Sass calculations (possibly due to flex gap?). Agreed that 600px seems more correct than 606px!


&:disabled {
background-color: ${forms.backgroundDisabledColor};
color: ${forms.controlDisabledColor};
Copy link
Contributor

Choose a reason for hiding this comment

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

I noticed this color changed noticeably and reducing the color contrast quite a lot. Is this expected?

Screen.Recording.2024-07-23.at.14.34.03.mov

before
Screenshot 2024-07-23 at 14 49 30

after
Screenshot 2024-07-23 at 14 49 22

Copy link
Member Author

Choose a reason for hiding this comment

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

IMO it's more correct as it matches our existing form controls/fields:

EuiFieldText

It's also worth noting that there are no WCAG color contrast requirements for disabled elements/buttons: https://sean-elliott.medium.com/a11y-tips-disabled-buttons-and-colour-contrast-f8824d5e9610

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed, that overall this change makes sense to align with other form controls. I was just wondering if we consider the contrast, but if that would be the case it's anyway a question on a broader level for forms I guess.

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, and this way/with this change, if we change contrast levels for all form components, this component will also update automatically :)

expect(componentUpdatedRefresh.prop('isPaused')).toBe(false);
const refreshButton = container.querySelector('.euiAutoRefreshButton');

expect(refreshButton).toBeInTheDocument();
Copy link
Contributor

Choose a reason for hiding this comment

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

Much cleanup, much nice 🧹

@cee-chen
Copy link
Member Author

Going to go ahead and merge this PR to move ahead on more EuiSuperDatePicker emotion work. If you have any other change requests that I didn't fully address I can grab it in a follow-up PR!

@cee-chen cee-chen merged commit 4ef461c into elastic:main Jul 23, 2024
5 checks passed
@cee-chen cee-chen deleted the emotion/super-date-picker-1 branch July 23, 2024 16:23
jbudz pushed a commit to elastic/kibana that referenced this pull request Aug 1, 2024
`v95.4.0` ⏩ `v95.5.0`

_[Questions? Please see our Kibana upgrade
FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)_

---

## [`v95.5.0`](https://github.com/elastic/eui/releases/v95.5.0)

- Added `minusInSquare` and `plusInSquare` glyphs to `EuiIcon`.
([#7875](elastic/eui#7875))

**Bug fixes**

- Fixed `EuiSuperDatePicker` not correctly passing `refreshMinInterval`
from the quick select popover
([#7905](elastic/eui#7905))

**CSS-in-JS conversions**

- Converted `EuiSuperDatePicker`'s form control to Emotion;
([#7904](elastic/eui#7904))
  - Removed `$euiSuperDatePickerWidth`
  - Removed `$euiSuperDatePickerButtonWidth`
  - Removed `$euiSuperDatePickerNeedsUpdatingBackgroundColor`
  - Removed `$euiSuperDatePickerNeedsUpdatingTextColor`
  - Removed `@euiSuperDatePickerText` mixin
- Converted `EuiSuperDatePicker`'s date popover content to Emotion
([#7908](elastic/eui#7908))
- Converted `EuiSuperDatePicker`'s quick select to Emotion
([#7909](elastic/eui#7909))

---------

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants