## Summary
This PR consolidates shared ux team dev docs similar how it was done by
operations team.
There is a separate "Shared UX" toc in the nav with the team's
catalogue. Also a landing page with our catalog.
<img width="1185" alt="Screenshot 2023-12-08 at 17 01 15"
src="c8e758f0-bcaa-4c74-9187-2911b2e7a680">
## Summary
Part of https://github.com/elastic/kibana-team/issues/646
Depends on https://github.com/elastic/kibana/pull/169324
Implements telemetry for fatal errors caught by KibanaErrorBoundary in:
-
`packages/core/application/core-application-browser-internal/src/ui/app_router.tsx`
- `packages/kbn-shared-ux-utility/src/with_suspense.tsx` [*]
- `packages/react/kibana_context/render/render_provider.tsx` [*]
-
`src/plugins/management/public/components/management_app/management_router.tsx`
-
`x-pack/plugins/observability_shared/public/components/page_template/page_template.tsx`
- `x-pack/plugins/security_solution/public/app/app.tsx`
[*] The changes made to these allowed the `analytics` dependency to be
provided optionally, to avoid a breaking API change for maintainers.
## Logging screenshot
You can trigger a fatal error in the new error boundary component in
most places in Kibana by adding a TypeError to a React component:
`<p>{breakHere()}</p>`
<img width="1586" alt="fatal error telemetry console log"
src="97f973ac-bb25-41f2-bfe2-547a23f2f450">
## Telemetry work info
Dashboard:
<img width="1382" alt="image"
src="4fe5353a-61ba-405a-ac18-0dd6a044c182">
Discover:
<img width="1331" alt="image"
src="2161b552-c441-4b7c-adef-25896147c08a">
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`v89.0.0`⏩`v89.1.0`
This upgrade also contains an EuiDataGrid refactor
(https://github.com/elastic/eui/pull/7255) not listed in the changelog
(as no end-user functionality or props changed as a result of the
refactor). The unlisted changes should only affect DOM and `className`
usages in Kibana (primarily CSS overrides and test selectors).
---
## [`89.1.0`](https://github.com/elastic/eui/tree/v89.1.0)
- Added `tokenVectorSparse` token and updated `tokenDenseVector` token
(now named `tokenVectorDense`).
([#7282](https://github.com/elastic/eui/pull/7282))
**CSS-in-JS conversions**
- Reduced default CSS prefixes generated by Emotion to only browsers
supported by EUI (latest evergreen browsers). This can be customized by
passing your own Emotion cache to `EuiProvider`.
([#7272](https://github.com/elastic/eui/pull/7272))
## 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`.
