-
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
[Logs+] Add Log Explorer profile deep link #161939
[Logs+] Add Log Explorer profile deep link #161939
Conversation
Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI) |
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
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.
Seems to work well 👍 I just left a question about the code organization below.
export type DeepLinkId = AppId; | ||
export type AppId = DiscoverApp | DashboardApp | VisualizeApp; | ||
|
||
export type DiscoverAppProfile = 'log-explorer'; |
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.
Would it be possible to keep the knowledge about the existence of the specific profile confined to the discover_log_explorer
plugin? Why would it have to live 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.
Based on the work done for using the deep link ids instead of the href, setting this type as part of the DeepLinkId union will allow accessing this deep link when it'll be referenced on the Observability serverless project navigation sidebar.
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.
Ah, I see. Would it make sense to move it to the observability deep links package, then?
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 can do it, I added this in the analytics package since the whole definition for discover was there, but make sense to have it in the obs package.
@@ -27,6 +27,8 @@ export type AppId = | |||
| ApmApp | |||
| MetricsApp; | |||
|
|||
export type DiscoverLogExplorerId = 'discover:log-explorer'; |
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.
Sorry for being so picky 😇 would it make sense to still interpolate DISCOVER_APP_ID
here?
…kibana into 161748-log-explorer-deeplink
Hey @isaclfreire, thanks for the review, I just pushed a change that allows us to customize the deep link with our preferred category (before, it was always using the parent app, in this case, Discover), I think it now looks as expected: |
Apparently, it didn't break anything (the failing tests were caused by the appUpdater not executing and updating correctly the state because the first emitted updater function was overridden by the
Totally, I didn't think about combining them, doing so we get the expected behaviour back, thanks for the suggestion! |
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, very nicely done 👏
customizationCallbacks: [callback, callback2], | ||
deepLinks: [], |
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.
Should we add a test to ensure the deep links are emitted correctly by the appupdater?
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.
Sure, I added a test for the registry behaviour and also a functional test as part of the customizations functional tests.
I'll make sure to also bring them into the serverless test suite in the follow-up work for [Log Explorer] Missing test suite for DatasetSelector in log-explorer profile#160627
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.
thank you!
map((profilesList) => { | ||
const mergedDeepLinks = profilesList.flatMap((profile) => profile.deepLinks ?? []); | ||
return getUniqueDeepLinks(mergedDeepLinks); | ||
}), |
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're applying getUniqueDeepLinks
in the next map
too, do we want to skip this duplicate call?
map((profilesList) => { | |
const mergedDeepLinks = profilesList.flatMap((profile) => profile.deepLinks ?? []); | |
return getUniqueDeepLinks(mergedDeepLinks); | |
}), | |
map((profilesList) => profilesList.flatMap((profile) => profile.deepLinks ?? [])), |
@@ -37,9 +37,11 @@ export default function ({ getPageObject, getService }: FtrProviderContext) { | |||
|
|||
// TODO: test something oblt project specific instead of generic discover |
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.
Can we consider this TODO to be completed?
@@ -79,11 +81,11 @@ export default function ({ getPageObject, getService }: FtrProviderContext) { | |||
it('navigate using search', async () => { | |||
await svlCommonNavigation.search.showSearch(); | |||
// TODO: test something oblt project specific instead of generic discover |
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.
Can we consider this TODO to be completed?
…kibana into 161748-log-explorer-deeplink
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.
Discover changes LGTM! 👍 I left a couple of very minor comments, but otherwise this approach makes sense to me. I followed the appUpdater
conversation and agree with moving the deep link logic to the customization profiles. I also appreciate that the Discover changes to make it function were fairly minimal.
I'm approving now since the code changes all look good to me, but it would be great if you could address my last couple of comments before merging.
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
Thanks for the repeated review, @davismcphee 🙏 I've applied your suggestions (except for the locator usage as explained in my response). |
Co-authored-by: Marco Antonio Ghiani <[email protected]> Co-authored-by: kibanamachine <[email protected]> Co-authored-by: weltenwort <[email protected]>
📓 Summary
closes #161748
The implementation registers an app updater on the
discover-log-explorer
plugin to update the deep link list.The deep link is accessible using the
discover:log-explorer
link.