[BUG] Refactor context menu

[joshuarrrr]

What is the bug?
The context menu component is very brittle and dependent on a number of OpenSearch Dashboards side effects that are not part of any public API. As OpenSearch Dashboards is refactored for OUI compliance, cohesion, and look and feel improvements, many of these hard-coded assumptions will break, leaving the current code non-functional.

How can one reproduce the bug?
A few, non-comprehensive examples:

1. These methods for determining the current app are all incorrect and brittle:

   dashboards-reporting/public/components/context_menu/context_menu.js

   Lines 255 to 276 in c8be18e

   	const isDiscoverNavMenu = (navMenu) => {
   	return (
   	navMenu[0].children.length === 5 &&
   	($('[data-test-subj="breadcrumb first"]').prop('title') === 'Discover' ||
   	$('[data-test-subj="breadcrumb first last"]').prop('title') ===
   	'Discover')
   	);
   	};
   	const isDashboardNavMenu = (navMenu) => {
   	return (
   	(navMenu[0].children.length === 4 || navMenu[0].children.length === 6) &&
   	$('[data-test-subj="breadcrumb first"]').prop('title') === 'Dashboard'
   	);
   	};
   	const isVisualizationNavMenu = (navMenu) => {
   	return (
   	navMenu[0].children.length === 3 &&
   	$('[data-test-subj="breadcrumb first"]').prop('title') === 'Visualize'
   	);
   	};

2. The nav menu integration tries to use class names instead of navigation plugin APIs. We will remove at least one of these class names soon (via [CCI] Remove unused tags in the navigation plugin OpenSearch-Dashboards#3964):

   dashboards-reporting/public/components/context_menu/context_menu.js

   Lines 280 to 282 in c8be18e

   	const navMenu = document.querySelectorAll(
   	'span.osdTopNavMenu__wrapper > nav.euiHeaderLinks > div.euiHeaderLinks__list'
   	);

3. HTML templates don't correctly position UI elements; UI controls must be rendered using actual OUI components:

   dashboards-reporting/public/components/context_menu/context_menu_ui.js

   Line 35 in c8be18e

   return `

What is the expected behavior?
Because the mentioned files don't use proper APIs, they may break at any time. They should be refactored to use interfaces that are subject to semver.

[joshuarrrr]

See https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/test/plugin_functional/plugins/osd_top_nav/public/plugin.tsx for an example of how to correctly register menu items via navigation.registerMenuItem().

[derek-ho]

Tagging this issue with 2.11 so it gets prioritized before next release. Temporary fix was already merged to 2.10

[anirudha]

This was broken due to a CCI contribution in 2.10 that was not tested with the reporting plugin. The issues here is in the pipeline as an enhancement to the code. New feature should not break existing implementations. We will prioritize this as work in order.

[ashwin-pc]

@anirudha this is more of a bug than an enhancement for sure and I wouldn't blame the CCI contribution. The way the context menu item is added is not using standard APIs and instead relies on css selectors that will definitely change in a minor or even patch release without notice. This has happened in 2.10 with the CCI improvement and again in the 2.11 release when we simply changed the top nav to remove the legacy discover toggle. It will likely again break in 2.12 and beyond unless fixed.

Additionally we should not expect platform code to validate it's changes against plugins as that's not scalable. We have quite a lot of plugins and that is not to mention 3rd party plugins. OSD already respects semver for all the explicit and implicit APIs that plugins today use. We can't expect platforms to also validate every change against all the plugins too.

[pjfitzgibbons]

Core services has core.application.currentAppId$. This can be used for conditional on which "app" is currently rendering.

There are two options for registering menu :

• navigation.registerMenuItem()
• chrome.navControls.registerCenter() (? is this the right services path)