[embeddable rebuild] integrate react control group embeddable into dashboard container - reloaded#192221
Conversation
…rd container (elastic#190273) (elastic#191993)" This reverts commit 86a63da.
|
/ci |
|
@elasticmachine merge upstream |
|
/ci |
|
/ci |
|
/ci |
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
src/plugins/dashboard/public/dashboard_container/embeddable/create/create_dashboard.ts
Show resolved
Hide resolved
src/plugins/dashboard/public/dashboard_container/embeddable/dashboard_container.tsx
Outdated
Show resolved
Hide resolved
|
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
async chunk count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
|
This PR introduces a major performance improvement for Dashboards which have both controls and saved searches, two embeddables which have been migrated to the new system (saved searches were moved here #180536). This improvement is consistently reproducible. After discussion with @Heenawter and @nreese , we are not 100% about the exact mechanics of how this large improvement was introduced, but it seems a compounding effect of the embeddable-refactor. It seems related to efficiencies in avoiding crufty re-rendering of React-DOM, and avoiding unnecessary state-diffing on state-change.
|



PR replaces legacy embeddable control group implementation with react control group implementation in DashboardContainer.
background
Work originally done in #190273. #190273 was reverted by #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 #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 #190273 minus some work to introduce a current regression in main. A full re-review is not needed.