## Summary
Unfortunately, #161914 regressed #162365 in that many plugins and their
Emotion styles (including EUI emotion styles) are now missing a cache
and are being appended to to the end of the document `<head>` as opposed
to within `<meta name="emotion">`.
What appears to be happening is many plugins are using a parent
`<KibanaThemeProvider>` but **not** a parent
`<KibanaRootContextProvider>` (not sure if this work is TBD or in
progress). This means that a parent `<EuiProvider>`, (which determines
the cache insertion of child Emotion styled components) is missing,
which is causing several CSS specificity bugs, e.g. around datagrid.
As a somewhat-bandaid-y fix, I've bogarted EUI's nested provider context
to check if the theme provider has a parent `EuiProvider`, and if it
doesn't, to use `KibanaEuiProvider` instead of `KibanaThemeProvider`.
This should set up the caches and context if needed, or otherwise simply
use the original `KibanaThemeProvider` component.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
## Summary
As titled. This PR corrects a pair of mistakes I made before committing
#161914 that @dgieselaar identified shortly thereafter.
- I had tested Storybook extensively, but after I rebased, I changed the
render context, and I forgot to update the `decorator` in Storybook.
This meant Emotion styles worked, but the EUI styles were missing.
- In addition, when I rebased, I missed the addition of the utils cache
that had been added by EUI.
- Interestingly, #162365 missed adding the cache `meta` tag to the
template. Emotion simply added the styles to the `head`, but it's best
to reproduce what we see in Kibana. So I've corrected that, as well.
- While creating the PR, I went ahead and addressed
[feedback](https://github.com/elastic/kibana/pull/161914#discussion_r1277765276)
from @cee-chen on the original PR./
Sorry if anyone was confused by the sudden drop in styles in their
Storybooks. Should be resolved now. Thanks!
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> Pre-req for https://github.com/elastic/kibana/issues/56406
## Summary
We've had a long-standing problem in Kibana around our use of React
context, particularly with EUI and i18n. There hasn't existed an
idempotent context structure, and that has lead to a lot of unexpected
results, (e.g. missing translations, inconsistent dark mode, excess
context providers, etc).
The biggest change coming from this PR is knowing exactly which provider
to use in a particular use case. This means, for example,
`ReactDOM.render` calls won't be missing `i18n` or `theme` due to a
missing context. It also allows consumers to use `darkMode` without
having to read the `uiSetting` themselves, instead allowing the context
to do it for them.
We also haven't been honoring the intended [`EuiProvider`
API](https://eui.elastic.co/#/utilities/provider#theming-and-global-styles)...
in some cases we've been creating and re-creating the Emotion caches,
often by copy/paste of the cache code. We've also been nesting
`EuiThemeProvider` contexts unnecessarily-- thinking we need to render a
theme provider in an isolated component-- which renders an additional
`span` element into the DOM.
This PR attempts to address this inconsistency by creating a set of
context providers divided by use case:
### `KibanaRootContextProvider`
A root context provider for Kibana. This is the top level context
provider that wraps the entire application. It is responsible for
initializing all of the other contexts and providing them to the
application. It's provided as a package for specific use cases, (e.g.
the `RenderingService`, cases where we replace the entire page content,
Storybook, testing, etc), but not intended for plugins.
### `KibanaRenderContextProvider`
A render context provider for Kibana. This context is designed to be
used with ad-hoc renders of React components, (usually with
`ReactDOM.render`).
### `KibanaThemeContextProvider`
A theme context provider for Kibana. A corollary to EUI's
`EuiThemeProvider`, it uses Kibana services to ensure the EUI Theme is
customized correctly.
### (deprecated) `KibanaStyledComponentsThemeProvider`
A styled components theme provider for Kibana. This package is supplied
for compatibility with legacy code, but should not be used in new code.
## Deprecation strategy
This PR does *not* change any use of context by consumers. It maps the
existing contexts in `kibanaReact` to the new contexts, (along with the
loose API). This means that we won't have completely fixed all of our
dark mode issues yet. But this is necessary to keep this PR focused on
the change, rather than drawing in a lot of teams to review individual
uses.
We should, however, see an immediate performance improvement in the UI
from the reduction in `EuiProvider` calls.
## Open questions
- [ ] Does it make sense to expose a `useTheme` hook from
`@kbn/react-kibana-context-theme` to replace `useEuiTheme`?
## Next steps
- [ ] Update deprecated uses to new contexts.
- [ ] Audit and update calls to `ReactDOM.render`.
- [ ] Add ESLint rule to warn for use of EUI contexts.
- [ ] Delete code from `kibanaReact`.
