[EuiGlobalStyles]: Support adding partial global styles

[mgadewoll]

Summary

relates to #7822

This PR updates EuiGlobalStyles to support conditionally enabling/disabling global base styles instead of completely disabling all added styles via <EuiProvider globalStyles={false} />
This would allow for a more flexible usage in non-Kibana specific contexts, e.g. EUI+.

The default behavior remains as is (all styles are enabled by default).

The new API allows to disable specific parts of the global styles manually, for example:

const CustomStyles = () => <EuiGlobalStyles hasReset={false} />

<EuiProvider globalStyles={CustomStyles} />

QA

• review the categorization of styles if it makes sense and is logical (there is currently no implementation of this yet to test)

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
  • Added documentation
  • Props have proper autodocs (using @default if default values are missing) and playground toggles
  • Checked Code Sandbox works for any docs examples
• Code quality checklist
  • Added or updated jest and cypress tests
  • Updated visual regression 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
  • Updated the Figma library counterpart

[kibanamachine]

Preview staging links for this PR:

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

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 1b8c4f1

History

• 💚 Build #2166 succeeded 496b964

[cee-chen]

I left a comment on the originating issue for this - generally, I'm not a huge fan of adding production-impacting features for non-production use cases, and would prefer we turn off EUI's global styles in docusaurus and recreate them manually if needed.

That being said, if we truly prefer this feature, I'd request that we add unit tests for each config/permutation and snapshot the CSS output. That being said, let's hold off on starting that until we determine whether we want to move forward and if we do, what granularity of customization is needed.

[github-actions]

👋 Hey there. This PR hasn't had any activity for 90 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[github-actions]

❌ We're automatically closing this PR due to lack of activity. Please comment if you feel this was done in error.