[App Menu Standardization] Integrate new app menu with discover#246156
[App Menu Standardization] Integrate new app menu with discover#246156kowalczyk-krzysztof merged 102 commits intoelastic:mainfrom
Conversation
25c41aa to
4c2e0d0
Compare
7e1ef56 to
ef4bb81
Compare
ef4bb81 to
fc51501
Compare
4502a72 to
4607268
Compare
4607268 to
27259bb
Compare
3b4b248 to
9f263e4
Compare
9f263e4 to
79651e6
Compare
davismcphee
left a comment
There was a problem hiding this comment.
Thanks for addressing all the feedback! The types are much easier to follow now 🙏
I did quite a bit of testing locally and overall it works great, also a huge improvement over the old app menu. I noticed a few minor issues, but I don't want to hold this up so I opened a small touchups PR against this branch with fixes: kowalczyk-krzysztof#15. With those changes, this will be all good to merge on my end!
src/platform/packages/shared/kbn-discover-utils/src/components/app_menu/app_menu_registry.ts
Outdated
Show resolved
Hide resolved
.../shared/discover/public/application/main/components/top_nav/app_menu_actions/get_inspect.tsx
Show resolved
Hide resolved
...ared/discover/public/application/main/components/top_nav/app_menu_actions/get_new_search.tsx
Outdated
Show resolved
Hide resolved
...discover/public/application/main/components/top_nav/app_menu_actions/run_app_menu_action.tsx
Outdated
Show resolved
Hide resolved
.../plugins/shared/discover/public/application/main/components/top_nav/discover_topnav_menu.tsx
Outdated
Show resolved
Hide resolved
...serverless/functional/test_suites/discover/group6/_unsaved_changes_notification_indicator.ts
Outdated
Show resolved
Hide resolved
src/platform/plugins/shared/discover/public/application/main/components/tabs_view/tabs_view.tsx
Show resolved
Hide resolved
src/platform/plugins/shared/discover/public/application/main/components/tabs_view/tabs_view.tsx
Show resolved
Hide resolved
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
References to deprecated APIs
Unreferenced deprecated APIs
History
|
davismcphee
left a comment
There was a problem hiding this comment.
Thanks for all the effort on this and fixing the Discover customizations test failure! Let's get this thing merged 👍
| * The HTML href attribute for the item. Only used if `items` is not provided. | ||
| */ | ||
| href: string; | ||
| /** | ||
| * The HTML target attribute for the item. Only used if `run` and `items` are not provided. | ||
| * The HTML target attribute for the item. Only used if `items` is not provided. | ||
| */ | ||
| target: string; | ||
| /** | ||
| * Function to run when the item is clicked. Only used if `items` and `href` is not provided. | ||
| * Function to run when the item is clicked. Only used if `items` is not provided. |
There was a problem hiding this comment.
This typing is confusing, you specify href, target as required, but then you say it's only used when items is not provided, but items is typed as never, I see the same thing also happen with AppMenuItemWithPopover, lets aggregate this into a discriminating union type on either on AppMenuItemBase or a simpler one that only focuses on run, target, and href for use in AppMenuLinkItem and AppMenuButtonItem since AppMenuItemWithPopover doesn't need these properties.
jughosta
left a comment
There was a problem hiding this comment.
Since the PR got merged while I was reviewing, please look into the mentioned issue as a followup work.
| ] | ||
| : [], | ||
| order: 4, | ||
| iconType: 'alert', |
There was a problem hiding this comment.
That's a design question, I think @andreadelrio chose those icons. It can be changed though.
There was a problem hiding this comment.
Let's take this one to the Monday team sync, I don't think it's a blocker.
| expect(screen.queryByText('Revert changes')).not.toBeNull(); | ||
| }); | ||
|
|
||
| test('should not show save in unsaved changed badge for read-only user', async () => { |
There was a problem hiding this comment.
Hmm this seems like an oversight. Because technically the read-only badge doesn't function like the rest of the badges. For example, in dashboard application, it's showing both on a dashboard page and and dashboard listing page using coreServices.chrome.setBadge which is different than the breadcrumbs badges.
So the question is, should read-only badge for discover be part of breadcrumbsBadges or like dahsboards, use coreServices.chrome.setBadge?
There was a problem hiding this comment.
Re-reading this. I see what's the problem. Discover is also using chrome.setBadge API but in the solution view, it places the read-only icon in the app menu region of chrome. Which discover doesn't have now since we combined app menu component with unified tabs.
So the solution here would be to use chrome.setBreadrumbsBadges like the rest of the badges. This means however the read-only badge will be next to breadcrumbs, which I'm not sure is what we want? @andreadelrio
There was a problem hiding this comment.
We would probably also want to position "Managed" badge somewhere close to it.
There was a problem hiding this comment.
Both Check out context-aware Discover and Managed badge use the new chrome.setBreadcrumbsBadges API to place the badge next to breadcrumbs. I guess making the read-only badge use the same API would make sense.
There was a problem hiding this comment.
This one might be bug with how the chrome badges API works, I'll have a look at it this afternoon.
There was a problem hiding this comment.
I think actually maybe reworking the setBadge API to work when there's no app menu in solutions view is an option too.
There was a problem hiding this comment.
Added an issue to track this: https://github.com/elastic/kibana-team/issues/2713
| }} | ||
| scopedHistory={appMountParams.history} | ||
| customizationCallbacks={[this.customizationCallback]} | ||
| customizationContext={{ displayMode: 'standalone' }} |
There was a problem hiding this comment.
Yeah this is because of the displayMode workaround to fix the test failures. I'll look at it this afternoon, but not too worried since our only actual customizations consumer is Timeline and it works fine there.
## Summary Follow up to #246156. It was pointed out in that PR that the Discover customizations example was broken due to changes related to the top nav customization. This PR fixes the issue, but also removes all the unused Discover customizations from the codebase. This is a legacy system we're trying to move away from in favour of context awareness, and they're a maintenance burden that provide no benefit. The following customizations have been removed, and the only two remaining are the ones currently used by Timelines: - Top nav - Data table - Field list - Flyout ### Checklist - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels.
## Summary Followup to #246156. This PR fixes the readonly badge in Discover, which was not showing in solution views after the new app menu changes. Since the `chrome.setBadge` API previously used doesn't work now that Discover's app menu is in the tabs bar, the code has been updated to use the same `chrome.setBreadcrumbsBadges` API that the managed and context awareness badges use. The readonly badge should appear in the same circumstances as before but directly next to the breadcrumbs (always the first badge), whether in classic or solution view. It should remain there while in the main app, surrounding docs, or single doc, and be removed when leaving Discover. I've also reordered the managed badge to appear next to the readonly badge when both are visible. ### Checklist - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. Closes: elastic/kibana-team#2713
…250332) ## Summary Noticed while testing #246156. It looks like closing the background search flyout in Discover doesn't return focus to the correct app menu button. This PR fixes that. It also fixes an issue where `EuiFlyout` was rendered twice for the background search flyout (caused by passing another `EuiFlyout` into `coreStart.overlays.openFlyout`). Afaict this didn't actually affect any functionality other than displaying a duplicate flyout backdrop overlay, but made the `onClose` callback misbehave, so I fixed it. ### Checklist - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels.




Summary
This PR introduces the new app menu component to discover application. As per design, discover won't have an actual app menu (it won't be mounted in the app menu region of the application) but instead it will incorporate the standalone component into unified tabs, which occupy the app workspace. However, in single tab view, the app menu will be mounted in the app menu region.
The design introduces a change to the
Switch to classicbutton, which now is part of the tab actions menu.Classic view (classic mode):

Classic view (ESQL mode):

Solution view (classic mode):

Solution view (ESQL mode):

Closes: https://github.com/elastic/kibana-team/issues/2350