This part is actually quite cool. I was thinking the other day about how I wish we could easily see the differences in the rendered CSS during PR reviews to tell if it's still working as before. The fact that they get added to the snapshots is fantastic for this 🥇

Caveat: Will this happen to every snapshot in consuming apps too? 😬

Depends on how they have their snapshot tests setup, but yes. It's possible for consuming apps to use a different serializer that would not add the styles.

Can this be added at a top level for apps? I'd hate to have to add something to every *.test file.

Yes, it's part of the global jest config

DevEx question: why pass a hook into a separate file? Why not just make euiMarkStyles useEuiMarkStyles and call useEuiTheme directly in that file?

Sorry, to be clear, I'm proposing this instead:

// mark.tsx
const styles = useEuiMarkStyles();

// mark.styles.ts
import { css } from '@emotion/react';
import { useEuiTheme, transparentize } from '../../services';

export const useEuiMarkStyles = () => {
  const { euiTheme, colorMode } = useEuiTheme();

  return css `// ... etc`;
};

Ah sorry, I see you addressed this in https://github.com/elastic/eui/pull/4575/files#r808436110 - I'm still not totally clear on the rationale behind that comment though. Is it a bad thing for a style file to be dependent on React context? TBH, keeping our usage of EUI theming to the style-focused file makes more sense to me from a developer POV.

I'm also very curious what usage would look like with a traditional class component (i.e.: can't use hooks) vs. a functional component. Do we have an example of that?

Did this so that it's possible to just pass in a theme shaped object and get styles, without needing the full React context. No reason we can't do a two-step thing for internal use. That is, keep euiMarkStyles context-agnostic, but add useEuiMarkStyles that is a convenience useEuiTheme() + euiMarkStyles(euiTheme) wrapper.

In more complex cases, we'll probably need to have useEuiTheme in the component file to do dynamic styles with the style prop. In that case this reduces the number of context calls. (More coming on the dynamic styles bit, likely in the EuiAvatar PR).

Gotcha! I think the benefits will be clearer with a dynamic styles example + a class component example (I assume we will need to use a HOC for class components). If we could add those examples to the TBD wiki section along with a basic example that would be amazing!