# Backport
This will backport the following commits from `main` to `8.x`:
- [[Embeddable Rebuild] [Controls] Remove non-React controls from
`controls` plugin
(#192017)](https://github.com/elastic/kibana/pull/192017)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Hannah
Mudge","email":"Heenawter@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-17T14:12:54Z","message":"[Embeddable
Rebuild] [Controls] Remove non-React controls from `controls` plugin
(#192017)\n\nPart of
https://github.com/elastic/kibana/issues/192005\r\nCloseshttps://github.com/elastic/kibana/issues/176533\r\n\r\n##
Summary\r\n\r\nThis PR represents the first major cleanup task for the
control group\r\nembeddable refactor. The tasks included in this PR can
be loosely\r\nsummarized as follows:\r\n1. This PR removes the old,
non-React version of controls \r\n- Note that the new controls are still
included under the\r\n`react_controls` folder - I will address this in a
follow up PR.\r\n2. This PR removes **all** types associated with the
old embeddable\r\nsystem; i.e. any `*input*` or `*output*` types.\r\n-
As part of cleaning up these types, some of the types included in
the\r\n`public/react_controls` folder had to be moved to `common` to
make them\r\navailable to server-side code.\r\n- This resulted in an...
unfortunate number of import changes 🫠 Hence\r\nthe rather large file
change count. I took this opportunity to organize\r\nthe imports, too -
so a significant chunk of these files are simply\r\nimport
changes.\r\n3. This PR removes the controls Storybook and all related
mocks\r\n- Since the controls storybooks have been broken for awhile,
and since\r\nwe had plans to remove them but never got around to it, I
just decided\r\nto delete them as part of this PR and
close\r\nhttps://github.com/elastic/kibana/issues/176533 rather than
spending\r\ntime to fix the types for non-operational stories\r\n\r\n###
Checklist\r\n\r\n- [x] Any text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"5082eef2f1df8b6d7e9bb15d2221b9f4c67b00bf","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Presentation","release_note:skip","impact:critical","v9.0.0","backport:prev-minor","project:embeddableRebuild"],"title":"[Embeddable
Rebuild] [Controls] Remove non-React controls from `controls`
plugin","number":192017,"url":"https://github.com/elastic/kibana/pull/192017","mergeCommit":{"message":"[Embeddable
Rebuild] [Controls] Remove non-React controls from `controls` plugin
(#192017)\n\nPart of
https://github.com/elastic/kibana/issues/192005\r\nCloseshttps://github.com/elastic/kibana/issues/176533\r\n\r\n##
Summary\r\n\r\nThis PR represents the first major cleanup task for the
control group\r\nembeddable refactor. The tasks included in this PR can
be loosely\r\nsummarized as follows:\r\n1. This PR removes the old,
non-React version of controls \r\n- Note that the new controls are still
included under the\r\n`react_controls` folder - I will address this in a
follow up PR.\r\n2. This PR removes **all** types associated with the
old embeddable\r\nsystem; i.e. any `*input*` or `*output*` types.\r\n-
As part of cleaning up these types, some of the types included in
the\r\n`public/react_controls` folder had to be moved to `common` to
make them\r\navailable to server-side code.\r\n- This resulted in an...
unfortunate number of import changes 🫠 Hence\r\nthe rather large file
change count. I took this opportunity to organize\r\nthe imports, too -
so a significant chunk of these files are simply\r\nimport
changes.\r\n3. This PR removes the controls Storybook and all related
mocks\r\n- Since the controls storybooks have been broken for awhile,
and since\r\nwe had plans to remove them but never got around to it, I
just decided\r\nto delete them as part of this PR and
close\r\nhttps://github.com/elastic/kibana/issues/176533 rather than
spending\r\ntime to fix the types for non-operational stories\r\n\r\n###
Checklist\r\n\r\n- [x] Any text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"5082eef2f1df8b6d7e9bb15d2221b9f4c67b00bf"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192017","number":192017,"mergeCommit":{"message":"[Embeddable
Rebuild] [Controls] Remove non-React controls from `controls` plugin
(#192017)\n\nPart of
https://github.com/elastic/kibana/issues/192005\r\nCloseshttps://github.com/elastic/kibana/issues/176533\r\n\r\n##
Summary\r\n\r\nThis PR represents the first major cleanup task for the
control group\r\nembeddable refactor. The tasks included in this PR can
be loosely\r\nsummarized as follows:\r\n1. This PR removes the old,
non-React version of controls \r\n- Note that the new controls are still
included under the\r\n`react_controls` folder - I will address this in a
follow up PR.\r\n2. This PR removes **all** types associated with the
old embeddable\r\nsystem; i.e. any `*input*` or `*output*` types.\r\n-
As part of cleaning up these types, some of the types included in
the\r\n`public/react_controls` folder had to be moved to `common` to
make them\r\navailable to server-side code.\r\n- This resulted in an...
unfortunate number of import changes 🫠 Hence\r\nthe rather large file
change count. I took this opportunity to organize\r\nthe imports, too -
so a significant chunk of these files are simply\r\nimport
changes.\r\n3. This PR removes the controls Storybook and all related
mocks\r\n- Since the controls storybooks have been broken for awhile,
and since\r\nwe had plans to remove them but never got around to it, I
just decided\r\nto delete them as part of this PR and
close\r\nhttps://github.com/elastic/kibana/issues/176533 rather than
spending\r\ntime to fix the types for non-operational stories\r\n\r\n###
Checklist\r\n\r\n- [x] Any text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"5082eef2f1df8b6d7e9bb15d2221b9f4c67b00bf"}}]}]
BACKPORT-->
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/189820
### Summary
This PR converts the `ControlGroupRenderer` to use the new control group
embeddable, which is built on the new React embeddable framework. With
this conversion, there should not be **any** changes in user-facing
behaviour - therefore, testing of this PR should be focused on ensuring
that no behaviour is changed and/or broken with this refactor.
**Notes to Solution Reviewers:**
- There should be minimal changes to your uses of `ControlGroupRenderer`
- our goal here was to keep the exposed API more-or-less consistent with
this refactor. Therefore, most changes are simply renames + changes of
imports.
- That being said, `updateInput` and `getInput$` are **very much** tied
to the old embeddable infrastructure - so while they will continue to
work for now, they have been deprecated in favour of adding
setters/getters for the parts of the control group state that you need
to update / respond to.
**Notes to Presentation Reviewer:**
- The bundle size was originally being increased by this PR, so I
decided to remove a bunch of the public exports that are no longer
necessary as a final cleanup - this resulted in changes to imports in a
few files, but it was worth doing in this PR IMO so that we didn't have
to increase the Controls bundle limit. Now, this PR shrinks the bundle
size 🎉
- I fixed a small bug with the default value of `showApplySelections` in
this PR - since it was a one-line change, if felt like overkill to
separate it out. See
https://github.com/elastic/kibana/pull/190561/files#r1733253015
### 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
### 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>
PR replaces legacy embeddable control group implementation with react
control group implementation in DashboardContainer.
#### background
Work originally done in https://github.com/elastic/kibana/pull/190273.
https://github.com/elastic/kibana/pull/190273 was reverted by
https://github.com/elastic/kibana/pull/191993 because of dashboard
performance degradation. It was determined that degradation was because
new react embeddable controls fixed a regression where dashboard panels
are loading before control filters are created. This regression was
introduced by https://github.com/elastic/kibana/pull/187509.
The work around is that this PR keeps the currently broken behavior in
main and loads panels before control filters are ready. The thinking is
that the migration would replace like for like and not introduce any
performance changes. Then, at a later time, the regression could be
resolved.
#### reviewing
These are the same changes from
https://github.com/elastic/kibana/pull/190273 minus some work to
introduce a current regression in main. A full re-review is not needed.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <hannah.wright@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
#190273 introduced a performance regression. Reverting to move metrics to baseline again and create some time to identify root cause.
Co-authored-by: Thomas Neirynck <thomas@elastic.co>
closes https://github.com/elastic/kibana/issues/191137,
https://github.com/elastic/kibana/issues/190988,
https://github.com/elastic/kibana/issues/191155
PR replaces legacy embeddable control group implementation with react
control group implementation in DashboardContainer.
### Test instructions
1. Open dashboard via dashboard application or portable dashboard
2. Mess around with controls. There should be no changes in behavior
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
PR added `lastUsedDataViewId$` to `ControlGroupApi`.
`lastUsedDataViewId$` is implemented in `initializeControlsManager`.
PR also cleaned up typings by removing `DataControlEditorState`.
`DataControlEditorState` was a weird smooshing together of
DefaultDataControlState and stuff used by the editor. Instead of
`DataControlEditorState`, values used by the editor are just passed in
as top level keys.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Move react_controls from examples plugin to controls plugin. This PR
does not effect user facing features since it does not effect the legacy
control group implementation or its usage. Future PRs will integrate the
new control group with dashboard and ControlGroupRenderer and then
remove the legacy control group implementation.
PR increases page load bundle size because of new action registration
and the control group react embeddable registration. This will be a
temporary increase as removing the legacy control group will remove the
legacy embeddable factory registration, which is larger then react
embeddable registration.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/189580
PR awaits until all control filters are ready and then applies
selections during reset.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/189407
## Summary
This PR adds an `order` attribute to the control factory so that the
ordering in the UI remains consistent - previously, the order was
determined by the order the factories were registered in (which is no
longer predictable now that the registration happens `async` - it's hard
to repro, but there were times where something delayed the options list
registration and it would appear at the end of my list). Adding and
sorting the UI based on the `order` of the factory removes this
uncertainty.
### 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
### 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)
## Summary
The range slider `value` was getting overwritten by the old value on
edit after the field name changed because we were passing in `value` as
part of the editor state manager - so, this resulted in the following
when editing a range slider with a defined `value` (for the sake of
clarity, let's say `value = [100, 200]`.
1. Change the field name to another number field (keeping it as a range
slider control) and save your changes
2. On save, the editor loops through the provided state manager key by
key and updates the control
3. The `fieldName` key is hit first because of the order of spread, so
this gets updated - which triggers the `fieldChangedSubscription` and
sets `value` to `undefined`
4. The `value` key gets hit afterward, which still has the old `[100,
200]` value because we don't clear up the dirty state - so, the editor
calls `value$.next([100, 200])`
5. The edited control now has the same selection as the old control
🔥
We should only add state to the editor state manager **that the editor
can change** - and since `value` is never changed via the editor,
removing this from the state manager fixes the above situation. I've
added a comment to hopefully clarify this.
### How to test
1. Create a range slider control and make a value change on it
2. Edit that control and pick a different data view and/or field - keep
it as a range slider control!
3. The value selected at step 1 **should be cleared**
### Before
https://github.com/user-attachments/assets/e6700538-deda-4196-8f52-c5446fa06518
### After
https://github.com/user-attachments/assets/be47fb2c-ecbf-4274-8beb-82a7e5462874
### 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)
While reviewing https://github.com/elastic/kibana/pull/188687, I noticed
that controls where still getting filtered by timeslider changes even
when chaining was disabled or the control was to the left of the
timeslider. This PR resolves this issue by only passing in timeslice
from `chaining$` instead of `controlGroupFetch$`.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
At the moment, our package generator creates all packages with the type
`shared-common`. This means that we cannot enforce boundaries between
server-side-only code and the browser, and vice-versa.
- [x] I started fixing `packages/core/*`
- [x] It took me to fixing `src/core/` type to be identified by the
`plugin` pattern (`public` and `server` directories) vs. a package
(either common, or single-scoped)
- [x] Unsurprisingly, this extended to packages importing core packages
hitting the boundaries eslint rules. And other packages importing the
latter.
- [x] Also a bunch of `common` logic that shouldn't be so _common_ 🙃
### For maintainers
- [x] 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>
PR does the following
* Adds `untilInitialized` to `ControlGroupApi`.
* Control group example updated to not mount data table react embeddable
until control group is initialized (and all control group filters are
available)
* Updates `buildControl` to be async
* Updates all controls to `await` filters before returning
`buildControl`
* Updates control group to display loading indicator until all controls
loaded
* Moves control group react logic into `ControlGroup` component
* Implements `Apply` button
<img width="600" alt="Screenshot 2024-07-24 at 7 33 25 AM"
src="https://github.com/user-attachments/assets/4840c731-2287-4a12-aa9c-3d9c83d64d14">
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes control editing so that, when the control type is changed,
extra state from the old type gets removed. Prior to this, controls were
keeping unrelated state - for example, switching from a range slider to
a search control would result in a search control with the "step"
property.
### 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
### 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)
Closes https://github.com/elastic/kibana/issues/187504
## Summary
This PR changes how control creation/editing is handled in the new
system by changing from a state manager to an explicit `initialState` +
`updateState` callback structure. Unfortunately, the `stateManager`
system really only works if we had inline creation for controls - since
we don't have that, the embeddable (and hence the `stateManager`)
doesn't exist until **after** the editor is saved. Therefore, especially
with respect to the custom options component, we had no way of knowing
what keys the `stateManager` should include when trying to create a new
control. The new system isn't quite as clean IMO, but it works better
for our current goals with this refactor. We can revisit the
`stateManager` idea once controls support inline editing 👍
This PR also fixes a few visual bugs, noted below.
### 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
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
### 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>
Closes https://github.com/elastic/kibana/issues/187382
## Summary
This PR separates out the previously memoized
`CompatibleControlTypesComponent` into a separate component that accepts
**props** for the fields that it is dependant on rather than relying on
the dependencies to the `useMemo` function. This is because, previously,
we had an extra dependency in the dependency array (`controlType`) that
was causing the memoized component to render too many times and it was
causing a weird bug where the old "disabled" menu item wasn't getting
unmounted properly.
| Before | After |
|--------|--------|
| 
| 
|
By switching to a component with explicit props, unnecessary
dependencies should hopefully be avoided in the future.
### 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)
## Summary
The primary goal of this PR is to clean up the styling of the
`ControlPanel` component for the new React control renderer.
Specifically, this fixes the following:
- I switched the inline Emotion styling to CSS classes instead
- I made it so that the timeslider control renders the drag handler in
edit mode and **doesn't** render the empty icon for the drag handler in
view mode
<p align="center"><img width="600px"
src="d5bf169b-2106-4f88-9698-f00162809d0a"/><p>
- I fixed the timeslider prepend so that it no longer wraps
<p align="center"><img width="500px"
src="7859d67b-1454-45b5-b7d8-7000086641a7"/><p>
- I moved the error component into the `EuiFormControlLayout` component,
which ensures that the drag handler is rendered for when a control has a
blocking error. I also fixed the styling for the error component:
<p align="center"><img width="600px"
src="13e0f041-8c51-494c-9079-323ed518c87b"/><p>
When I was working on these style changes, I noticed that the timeslider
control wasn't implementing `CanClearSelections` which meant that it no
longer had the clear selections action. This made me realize that this
interface should probably be part of the `DefaultControlApi` rather than
`DefaultDataControlApi` so, I moved it and added `clearSelections` to
the timeslider API.
<p align="center"><img width="600px"
src="47f7b648-bb2d-4158-b058-456bfdf5cdb5"/><p>
### Checklist
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
### 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>
Closes https://github.com/elastic/kibana/issues/184376
### Note for design review
index.scss file is just copy of
https://github.com/elastic/kibana/blob/main/src/plugins/controls/public/time_slider/components/index.scss.
We are migrating controls in the examples folder and then will migrate
these back into src folder once the migration is complete
### Changes
Changes to ControlGroupApi
* Implement timeslice$ API
* Implement autoApplySelections$
* Runtime state `autoApplySelections` is inverse of serialized state
`showApplySelections`
<img width="1000" alt="Screenshot 2024-06-11 at 12 56 45 PM"
src="dc27e3e3-6c25-4d5a-ab25-bfcc9bb38178">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <hannah.wright@elastic.co>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
PR updates initializeDataControl to handle error cases like DataView not
found and field not found.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/184373
## Summary
This PR marks the first step of the control group migration to the new
React embeddable system. A few notes about this:
- In the new system, each individual control will no longer be an
"embeddable" - instead, we are creating a **new** control-specific
registry for all controls. This is **modelled** after the embeddable
registry, but it is locked down and much more controls-specific.
- Most of the work accomplished in this PR is hidden away in the
`examples` plugin - that way, user-facing code is not impacted. After
some discussion, we decided to do it this way because refactoring the
control group to work with both legacy and new controls (like we did for
the dashboard container) felt like a very large undertaking for minimal
benefit. Instead, all work will be contained in the example plugin
(including building out the existing control types with the new
framework) and we will do a final "swap" of the legacy control group
with the new React control group as part of
https://github.com/elastic/kibana/issues/174961
- This PR does **not** contain a fully functional control group
embeddable - instead, the main point of this PR is to introduce the
control registry and an example control. The current control group
embeddable is provided just to give the **bare minimum** of
functionality.
- In order to find the new Search control example, navigate to Developer
Examples > Controls > Register a new React control
- The example search control only works on text fields. See
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html
and
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html
for information on the two search techniques.
### 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>
Aligns the Portable Dashboard renderer and the Control Group renderer to a new API structure using `useImperativeHandle` rather than the overcomplicated and mostly unused wrapper provider system.
## Summary
This PR adds the option to provide, custom props when calling
`openAddDataControlFlyout`. For example, users of the API may want
different placeholder than default for any new options list that is
added.
Currently, in security solution, we need a custom placeholder for newly
added controls. Hence, this PR. Please let me know if this is not the
best way to do this.
https://user-images.githubusercontent.com/7485038/232775198-a111d711-ffba-4d26-8c70-c2af08008e05.mov
Adds an "add" button that shows up to the right of the Control Group if
configured. Also adds a system for fetching settings from consumers, and
adds settings that can hide or show pieces of the Control editor flyout.
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR upgrades uuid into its latest version `9.0.0`.
The previous default used version `v4` was kept where it was previously
used and places using `v1` or `v5` are still using it.
In this latest version they removed the deep import feature and as we
are not using tree shaking it increased our bundles by a significant
size. As such, I've moved this dependency into the `ui-shared-deps-npm`
bundle.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/145428
PR does the following:
* Removes ControlsCallout
* Cleans up ControlGroupContainer API to avoid leaking Dashboard
implementation details
* Removes getCreateControlButton method
* Removes getCreateTimeSliderControlButton
* Removes getToolbarButtons
* Adds openAddDataControlFlyout
* Add Edit and save example
<img width="600" alt="Screen Shot 2022-12-21 at 9 29 21 AM"
src="https://user-images.githubusercontent.com/373691/208928858-94984880-3fdb-45f4-bb2a-a086bfc440d0.png">
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/145428
PR makes the following changes:
1) updates ControlGroupRenderer component with declarative properties
for filters, query, and timeRange.
2) creates a search example showing how to use controls to narrow
results
3) Updates redux example to use web logs sample data set
4) Updates existing uses of ControlGroupRenderer to use new props.
<img width="600" alt="Screen Shot 2022-12-14 at 4 29 58 PM"
src="https://user-images.githubusercontent.com/373691/207719012-28771203-27c3-45c0-a8ac-2bf96c10f641.png">
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
