[MD] Create data source selectable menu using context menu and allow it to be consumed by plugins via Nav bar

[BionIT]

Is your feature request related to a problem? Please describe.
In #5717, we implemented a data source picker in order to unify the experience when selecting data source in devtools, tutorial, etc. Based on requirement to place a data source selector into the navigation bar, we need to implement a new component based on context menu and be able to be consumed by external plugins via TopNavMenu.

Describe the solution you'd like
Implement a new component using context menu and allow external plugins to consume via TopNavMenu. The use of picker will be controlled by showDataSourceMenu property which is a boolean. We should also expose dataSourceMenuConfig which will contain customize options, eg, default option, disabled, filterFn, etc

There will be 2 states(read only vs selectable) for the data source selector in the nav bar, plugins need to decide which state to use based on which page user is at

Describe alternatives you've considered
Instead of having the selector in the nav bar, we can just let consumers to use the regular combo box based picker in the page.

Additional context

Add any other context or screenshots about the feature request here.

• [MD] Create data source menu component able to be mount to nav bar #6082
• [Multiple Datasource] Expose filterfn in datasource menu component to allow filter data sources before rendering in navigation bar #6113

[RamakrishnaChilaka]

Thanks Lu.

There will be 2 states(read only vs selectable) for the data source selector in the nav bar, plugins need to decide which state to use based on which page user is at

Can you please consider having this as an additional prop to know which component to mount, i.e., selectable vs readonly ?

[BionIT]

Thanks Lu.

There will be 2 states(read only vs selectable) for the data source selector in the nav bar, plugins need to decide which state to use based on which page user is at

Can you please consider having this as an additional prop to know which component to mount, i.e., selectable vs readonly ?

Hi @RamakrishnaChilaka, for readonly, we will need to have a separate component for plugins to use since the behavior would be different for readonly and selectable based on current requirement. We can go through how it would look like in the plugin you work on and see if we can make it easy to consume on your side

[seraphjiang]

Hi @RamakrishnaChilaka, for readonly, we will need to have a separate component for plugins to use since the behavior would be different for readonly and selectable based on current requirement. We can go through how it would look like in the plugin you work on and see if we can make it easy to consume on your side

+1 for not mixing the two components into one by following single responsibility principle.

actually, datasource context component might be more suitable name for second component base on requirement we know now. Though name is a little bit longer than readonly

[RamakrishnaChilaka]

Got it, Thanks Lu, Huan. Summarising offline discussion with Lu regarding passing dataSourceLabel as well to dataSourceCallBackFunc.

We need this because, Taking an example use case:
For ISM plugin, we need to show data source label in the index detail page and In this page, data source picker is in readonly mode. Hence, the label needs to be passed from the parent component, so it needs to be maintained in the parent state as well.

[derek-ho]

+1. Also adding context from security plugin perspective. Since we are going with a top nav menu header registration model, each individual tab will create a new instance of the ClusterSelector/DataSource Context component. Thus, we need some way to manage state within our plugin and be able to render the picker with a specific datasource selected. Thus, what ever datasource one is looking at for one tab will persist as they click to different tabs. Another use case where this may be helpful - some actions such as creation tabs where we are not allowing users to change cluster - I think is impossible to do without being able to pass in cluster selector (since it would default to local cluster with the picker disabled today).

[RamakrishnaChilaka]

@BionIT, Currently, DataSourceMenu takes both dataSourceId & dataSourceLabel for the selectedOption Prop in read only mode. This was required before because we expected plugins to render dataSourceLabel in a P/Div/custom label tag in read-only mode. However, the current data source menu implementation (in the main branch) handles the rendering for read-only mode. So, I think plugins don't need to store dataSourceLabel in their state. Only dataSourceId should be enough to determine which option to show as a label in read-only mode, correct?

@derek-ho, I believe, as data source id is unique across data sources, it can be used to identify which option to show as label in read-only mode.

[BionIT]

@derek-ho helped to create another issue to allow getting data source label when only data source id gets passed in #6274, and this existing issue can be closed since the selectable component have been exposed and can be mounted using the data source menu