[Emotion] Convert EuiKeyPadMenuItem

[cee-chen]

Summary

closes #6653

As always, I recommend following along by commit, as I included reasoning for various changes in commit messages, as well as misc cleanup items

🔲 Kibana follow-up items

• There's just one class modifier usage being used in a test selector that will be need to be updated in the next upgrade. IMO, usage is low enough that it's worth nuking all selectors

QA

• Compare staging against production, and confirm the component looks the same as before
  • NOTE: There will likely be some minute typography differences due to Emotion containing more up to date font and line height style changes. It should not be major however.
• gh checkout pr 7118
• Go to http://localhost:6006/?path=/story/euikeypadmenuitem--playground
• Play with various props (particularly permutations of isSelected, isDisabled, and checkable and confirm general UI/UX is working and non-broken

General checklist

• Checked in both light and dark modes
• Checked in Chrome, Safari, Edge, and Firefox
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

Emotion checklist

Kibana usage

• 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:
• Search Kibana's codebase for {euiComponent}- (case sensitive) to check for usage of modifier classes
  • [ ] If usage exists, consider converting to a data attribute so that consumers still have something to hook into - going to just look at the entire className string instead
• Any test/query selectors that will need to be updated - Yes, one
• 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

---

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)
  • Already added

---

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
• All SCSS files have been removed from the component(s) directory
• All SCSS overrides have been removed from the Amsterdam theme
• [ ] Any dependent components are identified in a new issue

---

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.

---

Extras/nice-to-have

• Reduced specificity where possible (usually by reducing nesting and class name chaining)
  • Note that this wasn't fully possible for all scenarios, e.g. when hovering a parent affects a child, or for affecting the fill color of SVG icons
• [ ] 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

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_7118/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_7118/

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: c90d3de

History

• 💔 Build #439 failed cdad94c

[breehall]

Love the optimizations within this PR! Storybook demonstrated the isSelected, isDisabled, and checkable props / permutations well.

[Just a note] This commit where you made the decision to simplify the color token -we should continue to do this where possible! I know it won't be easy in every case, but I think its beneficial as we improve accessibility (color contrast specifically) within EUI.

[breehall]

I vastly simplified the color functions down to basic tokens.

Given the recent conversation in Slack about color contrast and transparency, I think this was a good decision.

[cee-chen]

[Just a note] This commit where you made the decision to simplify the color token -we should continue to do this where possible! I know it won't be easy in every case, but I think its beneficial as we improve accessibility (color contrast specifically) within EUI.

Thanks for pointing this out, Bree! Just to follow up on the transparency topic as well, it's worth mentioning that dynamic color contrast calculations with transparency might be coming some day to native CSS functions, but right now there's no static contrast calculations that can be done with transparency and any dynamic calculations would require investigation.

[breehall]

Love the DRY object

[breehall]

the functions otherwise get redefined and recalled on every rerender

Great thinking & optimization

[cee-chen]

TBH, I've sometimes wondered whether all our emotion style objs should be memoized. We haven't run into any perf issues or complaints yet though, so I'm probably overthinking it 😅