[RFC] Wrapper component helper

[kavilla]

Proposal

Introduction

The wrapper component helper is to help OpenSearch Dashboards plugin developers to easily integrated into plugins and have a seemless experience from chat to plugin and from plugin to chat. Plugin developers can easily wrap their existing components with this component and register their plugin on setup and will gain access to the features available extended to them from the OpenSearch Assistant with minimal changes. While also integrating their plugin with the Assistant and empowering their users.

Architecture

Approach 1 [Preferred]:

Component and service is a 1st-party component. Meaning that this component and functionality is implemented and housed within the OSD core repo.

Pros:

• Plugin bundle is available for developers and plugin developers do not have to worry about the plugin bundle being installed.

Cons:

• The required components and features are already housed with Assistant repo. This makes accessing the features and feature development within the wrapper difficult and need to be exposed. If only the wrapper is housed in the core repo then we would have to async setup the component with features which carries risk.
• Anti-pattern architecture as it any required APIs that aren't apart of OpenSearch core live outside of this repo.
• Feature development specific to feature not available within core repos require more conditional checks to ensure no start up failures or no breaking changes to the open source community that do not consume the require plugins. By housing this code in core OSD repo. Development requires more time to ensure health of repo for non-Assistant users.

Approach 2:

Component and service is a 3rd-party component. Meaning that this component and functionality is implemented and housed within the Dashboards Assistant plugin repo.

Pros:

• The required components and features are already housed with this repo. This makes accessing the features and feature development within the wrapper easier.
• Unless all the APIs and features where housed in core repos (like security into OpenSearch and dashboards-security into OpenSearch Dashboards), then this design matches the preset architecture.
• Feature development specific to feature not available within core repos require more conditional checks to ensure no start up failures or no breaking changes to the open source community that do not consume the require plugins. By housing this code in this repo, we do not get slowed down by adding the guard rails.

Cons:

• Burden is on the plugin developers to implement their plugin to handle this plugin as an optionalPlugin or force the cluster admins to have this plugin as a requiredPlugin. However, plugin developers can conditionally check if the plugin is installed and this type of architecture is already highly supported within OpenSearch Dashboards ecosystem

Design

Plugins install and check if the Assistant plugin is available on setup and register. For example:

if (assistantDashboards) {
  // registerPalantir takes an array or single palantir
  assistantDashboards.registerPalantir([
    {
      // the key on the HTML element that will be wrapped with the component
      key: 'query_level_monitor',
      // description that will be available in the popover
      description: 'Monitoring on the query level',
     // suggestion that will be submitted to the chat assistant
      suggestion: 'How to better configure my monitor?',
    },
  ]);
}

Then plugins can wrap their component and it will decorate it and add the functionality. For example:
Before adding the new component:

<EuiLink
  data-test-subj={name}
  href={`${PLUGIN_NAME}#/monitors/${item.id}?type=${item.monitor.type}`}
>
  {name}
</EuiLink>

After adding new componet

<PalantirComponent>
  <EuiLink
    key={`${item.item_type}`}
    data-test-subj={name}
    href={`${PLUGIN_NAME}#/monitors/${item.id}?type=${item.monitor.type}`}
  >
    {name}
  </EuiLink>
</PalantirComponent>

As you can see, the only thing I needed to added was wrap my existing code with <PalantirComponent> and ensure my key was added to a child node that matches what I registered with to get the suggestion I added.

With this example the user flow would be:

User navigates to the page with the component that was wrapped. The child DOM gets wrapped and decorated with the component wrapper and passes through children:

User clicks on the wrapper icon to get the component popover:

User clicks the suggestion provided originally by the plugin. This then automatically asks the assistant this suggestion:

References

• Component pull request: [Incontext Insights] wrapper component and service #53
• Example plugin pull request: [OS-Assistant] example of usage of palantir component alerting-dashboards-plugin#852

TODOs

Possible implementation and design requirements

• Async propagation of suggestion
  • Failure case of propgation
• Pass information of child node in the React DOM that can further provide insight to Assistant or allow for token so a plugin can allow suggestions to support interpolation
• Final UX implementation
• Two-way interaction: from component to chat and chat to component functionality