-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Dashboard Navigation] Add Links to Visualization library #170810
[Dashboard Navigation] Add Links to Visualization library #170810
Conversation
f5f9582
to
6e58933
Compare
6e58933
to
89b806a
Compare
a === b ? 0 : a ? -1 : 1 | ||
); | ||
) | ||
.filter(({ disableCreate }: VisTypeAlias) => !disableCreate); |
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.
Since we are relying on the embeddable factory create
method for the link embeddable, we need to hide the visualization alias item from the dropdown.
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.
Good workaround. I'm thinking that as part of the Embeddable refactor, we should introduce a separate registry for creation buttons in the Dashboard top nav. That would make this more explicit and unified.
const closeEditorFlyout = (editorFlyout: OverlayRef) => { | ||
if (overlayTracker) { | ||
overlayTracker.clearOverlays(); | ||
} else { | ||
editorFlyout.close(); | ||
} | ||
}; |
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 can no longer assume that the overlayTracker
(from the Dashboard app) exists, since this flyout can now be opened outside of the Dashboard app - therefore, if the overlayTracker
does not exist, we need to rely on the normal flyout close
method.
@@ -128,8 +128,6 @@ export class LinksFactoryDefinition | |||
initialInput: LinksInput, | |||
parent?: DashboardContainer | |||
): Promise<LinksEditorFlyoutReturn> { | |||
if (!parent) return { newInput: {} }; |
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.
Similar to https://github.com/elastic/kibana/pull/170810/files#r1393019545, since the Link embeddable can now be edited outside of the Dashboard app, it is no longer considered invalid for a Link embeddable to not have a parent.
Note that this early return was actually unnecessary in the first place, because we already treat the parent as potentially undefined in the rest of the code - so, it's safe to remove.
src/plugins/visualizations/public/vis_types/vis_type_alias_registry.ts
Outdated
Show resolved
Hide resolved
Pinging @elastic/kibana-presentation (Team:Presentation) |
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.
Presentation team changes LGTM! Tested locally in chrome and looked through the code. Nice work getting the title click and the edit button to open the links editor.
a === b ? 0 : a ? -1 : 1 | ||
); | ||
) | ||
.filter(({ disableCreate }: VisTypeAlias) => !disableCreate); |
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.
Good workaround. I'm thinking that as part of the Embeddable refactor, we should introduce a separate registry for creation buttons in the Dashboard top nav. That would make this more explicit and unified.
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.
Shared UX code changes LGTM
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 like the direction this is going! Event annotations feature a similar library flyout editing experience.
But, why not divorce the Visualize app from the embeddable system?
I can see that the visualize app currently depends on the embeddable plugin, but the only usage is the one in this PR. I'd prefer we make the alias API generic and remove the visualize dependency on embeddables completely.
WDYT?
src/plugins/visualizations/public/vis_types/vis_type_alias_registry.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.
Looks great. Thank you.
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @Heenawter |
Closes #162840
Summary
This PR adds a visualization alias for the new Links embeddable so that all Links library items can be managed/edited from the Visualization library, like so:
Screen.Recording.2023-11-14.at.10.27.50.AM.mov
However, in order to get the above working, it was unfortunately not as simple as just adding a visualization alias. Because the Links embeddable does not have a dedicated editing app (all editing/creation is done through a flyout), the usual
aliasPath
+aliasApp
redirect that happens for editing an alias did not work in this case.To get around this, I've had to make changes to how aliases are registered, as well as both the Visualization
VisualizeListing
component and the genericTableListViewTableComp
content management component:Summary of visualization alias changes:
First off, I made changes to the typing of aliases - specifically, rather than taking two independent
aliasPath
andaliasApp
props, I've combined them into a singularalias
prop which will either be of type{ alias: string; path: string; }
or{ embeddableType: string; }
. This makes it easier to determine (a) whether a visualization is of typeBaseVisType
orVisTypeAlias
and (b) if it is of typeVisTypeAlias
, how the editing of that vis should be handled. Specifically, ifalias
is of type{ alias: string; path: string; }
, then it is a normal visualization and behaviour should be the same as it was previously; however, if it is of type{ embeddableType: string; }
, then this is an inline alias - i.e. editing should be done inline via the embeddable factory's edit method.Summary of
VisualizeListing
changesThe primary changes here were made to the
editItem
callback - specifically, if the fetched saved object has neither aneditApp
nor aneditUrl
, then it will now try to fetch the embeddable factory for the given saved object type and, if this factory exists, it will call thegetExplicitInput
method in order to handle editing.Summary of
TableListViewTableComp
changesPreviously, an error would be thrown if both a
getDetailViewLink
and anonClickTitle
prop were provided - while I understand the original reasoning for adding this catch, this no longer works if we want to support inline editing like this. In this case, I needed only the Link embeddable items to have anonClick
while keeping the behaviour for other visualizations the same (i.e. all other visualization types should continue to link off to their specific editor apps) - however, since this method is not provided per item, I had no way of making an exception for just one specific item type.Therefore, to get around this, it is now considered to be valid for both the
getDetailViewLink
andonClickTitle
props to be defined for theTableListViewTableComp
component. In order to prevent conflict between the two props, I have made it so that, if both are provided,getDetailViewLink
always takes precedence overonClickTitle
- in this case,onClickTitle
will only be called ifgetDetailViewLink
returnsundefined
for a given item. I have added a comment to hopefully make this clear for consumers.Checklist
For maintainers