-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compute dashboard panel selection list lazily #187797
Compute dashboard panel selection list lazily #187797
Conversation
5a9f898
to
b73af33
Compare
/ci |
b73af33
to
6b9e897
Compare
/ci |
fb6628d
to
461af98
Compare
/ci |
Pinging @elastic/kibana-presentation (Team:Presentation) |
d77ca3e
to
fcf2f79
Compare
...panelGroup, | ||
items: sortGroupPanelsByOrder<PanelSelectionMenuItem>( | ||
(panelGroup.items ?? []).concat( | ||
// TODO: actually add grouping to vis type alias so we wouldn't randomly display an unintended item |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this TODO
expected to be accomplished in this PR or in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say it outside the scope this PR, it would be handled in a different PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're also very close to removing Vis type aliases from this menu entirely, as the new Embeddable system uses only the ADD_PANEL_TRIGGER
trigger to determine what shows up here.
src/plugins/dashboard/public/dashboard_app/top_nav/editor_menu.tsx
Outdated
Show resolved
Hide resolved
src/plugins/dashboard/public/dashboard_app/top_nav/editor_menu.tsx
Outdated
Show resolved
Hide resolved
...ns/dashboard/public/dashboard_app/top_nav/add_new_panel/dashboard_panel_selection_flyout.tsx
Outdated
Show resolved
Hide resolved
} | ||
}); | ||
|
||
return _factoryGroupMap; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly, even with a platinum license, I'm not seeing any factories returned from the groupUnwrappedEmbeddableFactoriesMap
. Many embeddables have migrated to React embeddables which do not apply here. The remaining class based embeddables are excluded by other conditionals, e.g. Lens canCreateNew
returns false, Controls are containers, visualize exclusion is hard-coded.
Unless I'm missing something, we might be able to completely remove this function. But maybe we should wait until all class-based embeddables are removed? @nreese @ThomThomson what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great research! I think we should be removing this kind of dead-code as soon as we possibly can.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eokoneyo and I discussed offline and we agreed to remove this groupUnwrappedEmbeddableFactoriesMap$
function from the code. There are currently only eight embeddables that are returned from the getEmbeddablesFactories
method.
- dashboard - which is a container so it would be filtered out
- lens - which is filtered out because
canCreateNew
on the factory returnsfalse
. - search - is also filtered out because
canCreateNew
returnsfalse
. - visualization - is hard-coded to be filtered out
- controlGroup - is a container so it is filtered out
6 through 8. optionsList, rangeSlider, timeSlider which all return false
from the canCreateNew
method.
Additionally, all of these embeddables are in the process of being converted to React embeddables which are registered with the Add panel flyout using triggers. It is highly unlikely that Lens or Search embeddables will change the return value of their canCreateNew
methods before the conversion to React embeddables is complete. So I am confident in removing this legacy function.
2d3e6a2
to
1a90316
Compare
💔 Build Failed
Failed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
Unknown metric groupsESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
cc @eokoneyo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm! Thanks for removing the code handling the class-based embeddables. it is far simpler to read and removes a lot of legacy logic that is no longer needed.
code review and tested with both basic and premium licenses to verify the panel types appear correctly.
495f2b8
to
34f09a0
Compare
34f09a0
to
ffac8d7
Compare
x-pack/plugins/lens/public/trigger_actions/open_lens_config/create_action.tsx
Outdated
Show resolved
Hide resolved
ffac8d7
to
0550869
Compare
export async function isCreateActionCompatible( | ||
core: CoreStart, | ||
editorFrameService: EditorFrameService | ||
) { | ||
let isCompatible: boolean = core.uiSettings.get(ENABLE_ESQL); | ||
|
||
if (isCompatible && !getDatasourceMap() && !getVisualizationMap()) { | ||
const [visualizationMap, datasourceMap] = await Promise.all([ | ||
editorFrameService.loadVisualizations(), | ||
editorFrameService.loadDatasources(), | ||
]); | ||
|
||
if (visualizationMap && datasourceMap) { | ||
setDatasourceMap(datasourceMap); | ||
setVisualizationMap(visualizationMap); | ||
} else { | ||
isCompatible = false; | ||
} | ||
} | ||
|
||
return isCompatible; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given this PR introduces change to fetch only UIActions registered with the trigger ADD_PANEL_TRIGGER
it resulted in required data dependency that would have previously been made available when the classic lens Embeddable isEditable
method gets invoked (v8.14.3/x-pack/plugins/lens/public/embeddable/embeddable_factory.ts#L70-L73) being missing as evident in the failing test above. The above change ensures that the required data is articulated as a dependency of the action and exists before the action's execute method is invoked.
956193c
to
efe7994
Compare
rename function arg to prevent confusion with window.close
efe7994
to
9f3258a
Compare
x-pack/plugins/lens/public/trigger_actions/open_lens_config/create_action_helpers.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and reviewed for Lens code. LGTM 👌🏼
let isCompatible: boolean = core.uiSettings.get(ENABLE_ESQL); | ||
|
||
if (isCompatible && (!getDatasourceMap() || !getVisualizationMap())) { | ||
const [visualizationMap, datasourceMap] = await Promise.all([ | ||
editorFrameService.loadVisualizations(), | ||
editorFrameService.loadDatasources(), | ||
]); | ||
|
||
if (visualizationMap && datasourceMap) { | ||
setDatasourceMap(datasourceMap); | ||
setVisualizationMap(visualizationMap); | ||
} else { | ||
isCompatible = false; | ||
} | ||
} | ||
|
||
return isCompatible; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why introduce a side effect in the compatibility check?
Would it be best to move it within the execution flow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thought process here is, preemptively verify before execution that we'd have the data required to add the panel. Should this instead run at the execution point and we get no data back, the experience would mirror the failing test here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @eokoneyo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally on Safari and it works 👍
Summary
Closes #187587
This PR changes how the dashboard panel selection items get computed, it had previously been computed eagerly, in this implementation panel selection items would only be computed when the user actually clicks the
add panel
button, with it's results cached so that subsequent interactions with theadd panel
button leverages the already computed data.Notable Mention:
The options presented as the dashboard panel list now only comprise of uiActions specifically registered with the uiAction trigger
ADD_PANEL_TRIGGER
and specific dashboard visualisation types. See #187797 (comment) to follow the reasoning behind this.That been said adding new panels to the dashboard, would be something along the following lines;
Visuals
Untitled.mov
How to test
Checklist
Delete any items that are not applicable to this PR.