## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/176219.
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come in around 2 weeks.
These first PRs are simply preparing the code by wiring up the
`UserProvideService`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/190445
## Summary
This PR adds the first steps of a panel management API to the
`GridLayout` component:
- A method to delete a panel
- A method to replace a panel
- A method to add a panel with a given size and placement technique
(`'placeAtTop' | 'findTopLeftMostOpenSpace'`)
- Currently, we only support adding a panel to the first row, since this
is all that is necessary for parity with the current Dashboard layout
engine - we can revisit this decision as part of the [row
API](https://github.com/elastic/kibana/issues/195807).
- A method to get panel count
- This might not be necessary for the dashboard (we'll see), but I
needed it for the example plugin to be able to generate suggested panel
IDs. It's possible this will get removed 🤷
- The ability to serialize the grid layout state
I only included the bare minimum here that I know will be necessary for
a dashboard integration, but it's possible I missed some things and so
this API will most likely expand in the future.
https://github.com/user-attachments/assets/28df844c-5c12-40fd-b4f4-8fbd1a8abc20
### Serialization
With respect to serialization, there are still some open questions about
how we want to handle it from the Dashboard side - therefore, in this
PR, I opted to keep the serialization as simple as possible (i.e. both
the input and serialized output take identical forms for the
`GridLayout` component).
Our goal is to keep `kbn-grid-layout` as **generic** as possible so,
while I considered making the serialize method return the form that the
Dashboard expects, I ultimately decided against that; instead, I think
Dashboard should be responsible for taking the grid layout's serialized
form and turning it into a dashboard-specific serialization of a grid
layout and vice-versa for deserializing and sending the initial layout
to the `GridLayout` component.
The dashboard grid layout serialization will be tackled as part of
https://github.com/elastic/kibana/issues/190446, where it's possible my
opinion might change :) This is just a first draft of the
`kbn-grid-layout` API, after all.
### Example Grid Layout
In the grid layout example plugin, I integrated the API by adding some
pretty bare-bones buttons to each panel in order to ensure the API works
as expected - that being said, I didn't worry too much about the design
of these things and so it looks pretty ugly 😆 My next step is
https://github.com/elastic/kibana/issues/190379, where I will have to
integrate the grid layout API with the embeddable actions, at which
point the design will be improved - so this is a very temporary state
🙇
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
