[MD][Oui] DataSourcePickup

[seraphjiang]

Is your feature request related to a problem? Please describe.

OSD introduced multiple datasource feature which allow user to create and connect to remote data sources. Then it could be selected when used in Dashboards/Visualization/Discover and plugins.

The functionalities we'd like to support are:

1. Be able to show list of data sources, read from saved object data source type -- must have
2. Be able to refresh the list -- Optional
3. Be able to filter list by keywords -- must have
4. Be able to remember selected data sources per user or per browser session -- optional
5. Be able to select one data source -- must have
6. Be able to select multiple datasource for the plugins support that -- optional

Properties:

• Title or Description. - readonly
• Input Text for customer to type/filter -- input
• List to display data source -- input
• Selected Items -- output

Width: set by developer
Height: set by developer

For dashboards anywhere - multiple datasource project in 2.5, we are looking for all must have functionalities, in order to support dev tool. We are looking for build-in Oui component support. If Oui doesn't support, We should review if need to create as global component. We are open to compose and build this component with existing Oui.

#2699

[seraphjiang]

@zhongnansu @kristenTian @KrooshalUX team please review the initial feature request

cc: @kgcreative

[seraphjiang]

Adding reference issue logged

opensearch-project/oui#95
opensearch-project/oui#51

CC: @ashwin-pc @rednaksi91

[kristenTian]

Great proposal, reading through the issues, the "xxxPicker" UI element should be a reusable one across all use cases while supporting all the requirements.

[ashwin-pc]

I'd split this issue into two parts. The OUI section of the issue is to ask for either support or guidance on an OUI element that san be used to satisfy the features that this feature is asking for.

• Select a single or multiple option
• Filter options using search
• Ability to display options in a custom way.

opensearch-project/oui#95 talks about this.

The other part is specific to dashboards, which is to introduce a common datasource picker element that uses the suggested OUI element (Some version of select and popover) to build a uniform Datasource picker that can be used in multiple locations across the app.

The non OUI features in my option are:

• session persistence
• how to display the datasource property (The base OUI component should have the flexibility to show such an option though)
• Refreshing the list
• Read from saved object data. This one concerns me a little because again this goes against how datasources are transparent to the plugins that use existing high level data plugin abstractions. e.g. VisBuilder. A little more detail about this would be helpful.

Also Visualizations can today reference an index pattern or saved searches when creating a visualization. How does this datasource picker integrate with that?

We also select the indexpattern or saved search before we create the visualization. Are we adding another datasource picker inside visualize to change the existing source? If so how would that work?

[KrooshalUX]

I'll be opening an issue to propose a composition for a data source ' picker in the UX repo. It will be composed of existing OUI primitives which may need additional iteration I anticipate would take a single sprint to execute in time for 2.5. It combines these and requirements from other projects into consideration.

[kgcreative]

@ashwin-pc -- a meta question that your comment brings up, is how do we want to address higher order components for Dashboards, and where should those live. Should those be part of OUI? Should we move some of those to Dashboards Core? Should we split OUI primitives from Dashboards Core common components and interfaces? Right now OUI seems to be a combination of both

[ashwin-pc]

@kgcreative Thats a much bigger OUI discussion that would also mean a significant restructure of how we use and build OUI as a whole and warrants a separate thread/issue. The current approach allows for composed components to exist in OUI if they are highly reuseable and abstract. A design system purist will barf at that but I actually like the architecture. It abstracts away a lot of the compositional pain points and makes doing the right UX thing easier since there are less variables at play for the dev who uses them.

thats why I suggested that even here we should ideally have a single OUI component that satisfies the UI need in an abstract way (a reuseable picker with the required customization options) while we keep the implementation details (The DATASOURCE picker part of it) in OSD

[KrooshalUX]

@kgcreative @ashwin-pc Lets move the discussion about higher order components over to OUI repo. I have several philosophical threads to bring to GitHub for broader participation that will inform our approach to composed components , atomic components and props organization.

As it applies to this request for a “data source picker”, my goal is to orchestrate a composition of existing components that would further extend an existing picker we have (ComboBox) and create under a generic wrapper name so its use is not limited to Data Source alone.

[legitYosal]

Any update on this?

[ashwin-pc]

@legitYosal Take a look at this proposal #4991

[seraphjiang]

closing it in favor of #6216