[Discover] Minor embeddable/controls cleanups#250336
[Discover] Minor embeddable/controls cleanups#250336davismcphee merged 5 commits intoelastic:mainfrom
Conversation
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
History
cc @davismcphee |
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
| getTooltipForSavedObject, | ||
| }: { | ||
| onAdd: RegistryItem['onAdd']; | ||
| onAdd: RegistryItem<TSavedObjectAttributes>['onAdd']; |
There was a problem hiding this comment.
Can you explain why this type change is needed? I'm aware that it's currently quite tied to the Saved Object typings, but we are trying to move it away from that, and I'd prefer not to introduce a new linkage. Is there any way you can leave off this generic type and cast it on your side?
There was a problem hiding this comment.
It's not needed, just seemed correct to type it with the already provided TSavedObjectAttributes vs re-casting on our end. I thought omitting It was accidental tbh, seems confusing otherwise. But I can revert it, done here: b0fddf7.
There was a problem hiding this comment.
Thanks for the revert, we have plans to decouple this bit from content management (and saved objects in general) because eventually these should be the return types of various panel-level APIs, not saved objects directly.
## Summary Just a couple of minor cleanups I've been meaning to do after the controls anywhere elastic#245588 PR merged, mainly pulling the `addPanelFromLibrary` out of the plugin file. ### Checklist - [ ] 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/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [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) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Summary
Just a couple of minor cleanups I've been meaning to do after the controls anywhere #245588 PR merged, mainly pulling the
addPanelFromLibraryout of the plugin file.Checklist
release_note:breakinglabel should be applied in these situations.release_note:*label is applied per the guidelinesbackport:*labels.