[Emotion] Convert EuiCode and EuiCodeBlock

[miukimiu]

Summary

This PR converts EuiCode and EuiCodeBlock to Emotion.

Some parts of the EuiCodeBlock are now split into new components:

• src/components/code/code_block_full_screen_button.tsx
• src/components/code/code_block_full_screen_wrapper.tsx

Some functions were moved to the src/components/code/utils.tsx:

• useOverflowDetection
• useCopy
• useFullScreen
• ListRow

Color codes variables and the mixin euiCodeSyntaxTokens now live in:

• src/components/code/code_syntax.styles.ts

QA

Remove or strikethrough items that do not apply to your PR.

General checklist

• Checked in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• Props have proper autodocs and playground toggles
• Added documentation
• Checked Code Sandbox works for any docs examples
• Added or updated jest and cypress tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• Updated the Figma library counterpart
• A changelog entry exists and is marked appropriately

Emotion conversion checklist

• Does it work?
• Output CSS matches the previous CSS / as expected in browsers
• Rendered className reads as expected in snapshots and in browsers
• Checked component playground (class components wrapped in withEuiTheme need to pass true as the second argument to propUtilityForPlayground)
   
• Unit tests
• shouldRenderCustomStyles() test was added and passes with parent component and any nested childProps (e.g. tooltipProps)
• Removed any mounted snapshots in favor of render() or a more specific assertion
   
• 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 removals in changelog, and ran yarn compile-scss to update JSON files
• Added an @warn deprecation message within the global_styling/mixins/{component}.scss file
• Removed component from src/components/index.scss
• Deleted any src/amsterdam/overrides/{component}.scss files (styles within should have been converted to the baseline Emotion styles)
   
• CSS tech debt
• Reduced specificity where possible (usually by reducing nesting and class name chaining)
• 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)
• Deleted any modifier classNames or maps if not being used in Kibana. Before doing this step:
  • Search/grep through Kibana's codebase for {euiComponent}- (case sensitive) to check for source code usage of modifier classes
  • If usages exist, consider converting to a data attribute so that consumers still have something to hook into
     
• 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
• Any Sass or CSS that will need to be updated, particularly if a component Sass var was deleted
• 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)
   
• Extras/nice-to-have
• Documentation pass:
  • Converted any remaining .js docs files to TS
  • Misc cleanup of docs code (e.g. combine imports to single from '../src', replace <React.Fragment> with <>)
• 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_6263/

[kibanamachine]

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

[kibanamachine]

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

[kibanamachine]

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

[cee-chen]

@miukimiu sorry it took me so long to get to this PR today - can I ask if there's a specific reason why you're using Emotion globals for the token mixin instead of just leaving them as a direct descendant mixin of the Emotion-generated euiCodeBlock styles? Is it a performance/stylesheets thing, or something else? TBH we just left all our nested descendants in for, e.g. EuiText so I feel that we should do the same for EuiCode.

edit to add: the Global styles are what's causing the test useLayoutEffect warnings/failures.

[kibanamachine]

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

[miukimiu]

Thanks, @constancecchen for the help. 🎉

can I ask if there's a specific reason why you're using Emotion globals for the token mixin instead of just leaving them as a direct descendant mixin of the Emotion

I thought that it would improve the performance. Instead of repeating the same code on every EuiCode or EuiCodeBlock render, it would just render once globally. But maybe that was not even happening... 😬

For me, leaving it as a direct descendant mixin of both components is okay. 👍🏽

[cee-chen]

Gotcha - yeah in this case the performance hit/extra output is a necessary evil, just IMO. It's basically the same output as EuiText.

[kibanamachine]

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

[kibanamachine]

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

[cee-chen]

@miukimiu I'm doing another quick pass on this in hopes of getting this PR in an approval-ready state before I go. Just wanted to flag that I strongly disagree with the choice to move several hooks and sub-components to the utils file. That file was previously concerned with Refractor/AST related logic and throwing in React-related logic is just shuffling code from one file to another / making another file slightly harder to read without actually organizing them by concept. If no objections I'm going to do a very opinionated architectural pass on the folder 🙈

[kibanamachine]

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

[cee-chen]

OK, I think I'm all done tinkering. This feels much cleaner to me personally, especially code_block.tsx. Really appreciate you going the extra mile Elizabet!

[kibanamachine]

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

[kibanamachine]

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

[kibanamachine]

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