Closed qn895 closed 1 week ago
@qn895 I am linking your PR with this one. For now, each embeddable that migrates to the new architecture, needs to add the data-shared-item
attribute, so that Kibana reporting screenshot tool doesn't complain with timeout error.
/ci
/ci
/ci
/ci
Pinging @elastic/ml-ui (:ml)
/ci
/ci
/ci
/ci
Thanks @davismcphee and @peteharverson for testing. Per @ThomThomson's recommendation, I have migrated the field statistics table off the embeddable architecture and instead simply things by exposing it as a React component that Discover can consume. I've updated the PR description with the additional context to the change.
I've also fixed the issue with filters now. With the update, I think it works correctly now with the navigation via browser, but some additional testing would be appreciated. Also one thing to note is that for text fields (like agent
field in Kibana sample data logs), it can only sample 1000 documents maximum. So if the dataset returns 1000+ hits, it will still only show 1000.
https://github.com/elastic/kibana/assets/43350163/c55d6a3f-1919-4b54-93ed-23d2181d3f34
https://github.com/elastic/kibana/assets/43350163/4f014826-ebbc-4a50-92bf-be7d0ad1de95
https://github.com/elastic/kibana/assets/43350163/da0bd647-0853-4a21-bf5d-4d2711580ac9
The saved search dashboard field statistics panel will also try to retain both the filters from the original saved search as well as the dashboard.
https://github.com/elastic/kibana/assets/43350163/eaf8ea58-302b-4235-adc1-a23d1483d182
I found this issue with filters and the browser history. If you add a filter, then edit it, hitting the 'back' button takes you to a state where you end up with the original and edited filter:
https://github.com/elastic/kibana/assets/7405507/9339da9e-0661-4235-91ac-82ad9ef9bc18
I have migrated the field statistics table off the embeddable architecture and instead simply things by exposing it as a React component that Discover can consume.
This looks great! Thank you for doing this. One small nitpick is that some of the files / components still have embeddable
in the name. If it isn't too much trouble I'd recommend removing that to avoid confusion.
Additionally, if you'd still like to place this on its own on a Dashboard in the future, feel free to reach out to @elastic/kibana-presentation - it should still be a straightforward process.
Thanks Pete for catching that. I've fixed it here.
@ThomThomson Thanks for the guidance! I kept some of the naming/type as is cause we plan to add it as a dashboard panel in 8.15 so this will lessen some of the work we have to do then.
@elasticmachine merge upstream
@elasticmachine merge upstream
@elasticmachine merge upstream
Fewer modules leads to a faster build time
id | before | after | diff |
---|---|---|---|
dataVisualizer |
645 | 647 | +2 |
Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app
id | before | after | diff |
---|---|---|---|
dataVisualizer |
656.1KB | 671.8KB | +15.7KB |
discover |
638.3KB | 641.6KB | +3.3KB |
total | +19.0KB |
Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0.
Run node scripts/build_api_docs --plugin [yourplugin] --stats exports
for more detailed information.
id | before | after | diff |
---|---|---|---|
dataVisualizer |
3 | 4 | +1 |
Size of the bundles that are downloaded on every page load. Target size is below 100kb
id | before | after | diff |
---|---|---|---|
dataVisualizer |
23.8KB | 23.0KB | -818.0B |
discover |
35.1KB | 35.1KB | +32.0B |
total | -786.0B |
To update your PR or re-run it, just comment with:
@elasticmachine merge upstream
cc @qn895
Status | Branch | Result |
---|---|---|
❌ | 8.14 | Backport failed because of merge conflicts |
To create the backport manually run:
node scripts/backport --pr 181502
Please refer to the Backport tool documentation
Summary
Addresses https://github.com/elastic/kibana/issues/174965. This PR refactors Field statistics table from an embeddable to a async React component.
Context Initially when embeddable was implemented, we could not register dataVisualizer as an optional plugin due to the cyclical dependencies and enforced package import rules (from x-pack to discover). However, due to changes in the infrastructure in the last few years, we can now register x-pack plugins as a dependency. This eliminates the need for an embeddable as a wrapper around the field statistics table.
Reviewer's note
dataVisualizer
plugin is now added as an optional dependency in DiscoverdataVisualizer
plugin is now added as an optional dependency in Discover,discover
removed from Data visualizer pluginhttps://github.com/elastic/kibana/assets/43350163/7800291a-ad8c-447e-9bfc-e4f279b05d6a
https://github.com/elastic/kibana/assets/43350163/d7422e11-a0c7-4a8b-8f47-783e453f02a8
Follow up after this PR:
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers