[Emotion] Convert EuiSearchBar

[cee-chen]

Summary

This is a pretty quick/mildly dirty Emotion conversion of EuiSearchBar, due to the nature of the class component (harder to use hooks for) and very minor CSS (only 2 rules, nothing on the main wrapper, just child elements). I strongly recommend viewing the diff with whitespace changes hidden.

While I was here, I also refactored some of the rendered JSX to not use a variable unnecessarily (which has react perf implications) but instead as an inline JSX conditional.

QA

• Compare staging against production and confirm no UI regressions

General checklist

• Browser QA
  • Checked in both light and dark modes
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
• Docs site QA - N/A
• Code quality checklist - N/A
• Release checklist
  • A changelog entry exists and is marked appropriately.
• Designer checklist - N/A

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 - No modifier classes changed
• 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

---

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 No playground

---

Unit tests

• [ ] shouldRenderCustomStyles() test was added and passes with parent component and any nested childProps (e.g. tooltipProps)
  • N/A, this component doesn't appear to pass any custom classNames or styles
• Enzyme tests converted 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
• [ ] 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 No overrides

---

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. No DOM or className changes/removals

---

Extras/nice-to-have

• [ ] Reduced specificity where possible (usually by reducing nesting and class name chaining) Wasn't necessary
• [ ] 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

[cee-chen]

This very likely has performance implications as well (see #7486) and we likely need to memoize euiFormVariables (and other CSS-in-JS component style vars) going forward. I'll address that in a separate PR from this one

[kibanamachine]

Preview staging links for this PR:

• Docs site: https://eui.elastic.co/pr_7490/
• Storybook: https://eui.elastic.co/pr_7490/storybook

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 8781e63

[JasonStoltz]

LGTM. I had one question about logical CSS properties that's not a blocker.

[JasonStoltz]

DELETED

[JasonStoltz]

While I was here, I also refactored some of the rendered JSX to not use a variable unnecessarily (which as react perf implications) but instead as an inline JSX conditional.

That's wild that this has a performance implication, I had no idea. I assume this is what you're referring to. I'm going to link to this change specifically as a reference on #7499

[cee-chen]

Kevin chatted about me with this in relation to #7374, but iirc the issue is that React creates the conditional node let as a new React component every single rerender. @kqualters-elastic feel free to chime in if I've misquoted you!