Skip to content
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

Merged
merged 17 commits into from Nov 22, 2023

Conversation

Heenawter
Copy link
Contributor

@Heenawter Heenawter commented Nov 7, 2023

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 generic TableListViewTableComp 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 and aliasApp props, I've combined them into a singular alias 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 type BaseVisType or VisTypeAlias and (b) if it is of type VisTypeAlias, how the editing of that vis should be handled. Specifically, if alias 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 changes

    The primary changes here were made to the editItem callback - specifically, if the fetched saved object has neither an editApp nor an editUrl, then it will now try to fetch the embeddable factory for the given saved object type and, if this factory exists, it will call the getExplicitInput method in order to handle editing.

  • Summary of TableListViewTableComp changes

    Previously, an error would be thrown if both a getDetailViewLink and an onClickTitle 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 an onClick 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 and onClickTitle props to be defined for the TableListViewTableComp component. In order to prevent conflict between the two props, I have made it so that, if both are provided, getDetailViewLink always takes precedence over onClickTitle - in this case, onClickTitle will only be called if getDetailViewLink returns undefined for a given item. I have added a comment to hopefully make this clear for consumers.

Checklist

For maintainers

@Heenawter Heenawter added release_note:enhancement Feature:Dashboard Dashboard related features Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:medium Medium Level of Effort impact:medium Addressing this issue will have a medium level of impact on the quality/strength of our product. backport:skip This commit does not require backporting Project:Dashboard Navigation Related to the Dashboard Navigation Project labels Nov 7, 2023
@Heenawter Heenawter self-assigned this Nov 7, 2023
@Heenawter Heenawter force-pushed the links-register-alias_2023-10-17 branch 7 times, most recently from f5f9582 to 6e58933 Compare November 10, 2023 23:02
@Heenawter Heenawter force-pushed the links-register-alias_2023-10-17 branch from 6e58933 to 89b806a Compare November 14, 2023 15:32
a === b ? 0 : a ? -1 : 1
);
)
.filter(({ disableCreate }: VisTypeAlias) => !disableCreate);
Copy link
Contributor Author

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.

Copy link
Contributor

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.

Comment on lines +61 to +67
const closeEditorFlyout = (editorFlyout: OverlayRef) => {
if (overlayTracker) {
overlayTracker.clearOverlays();
} else {
editorFlyout.close();
}
};
Copy link
Contributor Author

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: {} };
Copy link
Contributor Author

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.

@Heenawter Heenawter marked this pull request as ready for review November 14, 2023 22:06
@Heenawter Heenawter requested review from a team as code owners November 14, 2023 22:06
@Heenawter Heenawter requested review from a team as code owners November 14, 2023 22:06
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

@ThomThomson ThomThomson self-requested a review November 14, 2023 22:06
Copy link
Contributor

@ThomThomson ThomThomson left a 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);
Copy link
Contributor

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.

Copy link
Contributor

@vadimkibana vadimkibana left a 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

Copy link
Contributor

@drewdaemon drewdaemon left a 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?

Copy link
Contributor

@drewdaemon drewdaemon left a 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.

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
visualizations 807 804 -3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
canvas 1013.8KB 1013.8KB +59.0B
dashboard 377.2KB 377.2KB -32.0B
eventAnnotationListing 196.9KB 196.8KB -89.0B
filesManagement 90.0KB 89.9KB -89.0B
graph 388.2KB 388.2KB -89.0B
links 25.2KB 25.3KB +120.0B
maps 2.9MB 2.9MB -89.0B
visualizations 268.1KB 268.1KB +66.0B
total -143.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
lens 37.2KB 37.2KB +7.0B
links 33.0KB 33.6KB +658.0B
maps 46.7KB 46.7KB +7.0B
visualizations 57.1KB 57.1KB +9.0B
total +681.0B
Unknown metric groups

API count

id before after diff
visualizations 837 835 -2

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @Heenawter

@Heenawter Heenawter merged commit 8eaebb6 into elastic:main Nov 22, 2023
29 checks passed
@Heenawter Heenawter deleted the links-register-alias_2023-10-17 branch November 22, 2023 17:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Dashboard Dashboard related features impact:medium Addressing this issue will have a medium level of impact on the quality/strength of our product. loe:medium Medium Level of Effort Project:Dashboard Navigation Related to the Dashboard Navigation Project release_note:enhancement Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.12.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Dashboard Navigation] Register alias with Visualizations plugin
9 participants