[Incontext Insights] wrapper component and service

[kavilla]

Description

Registry and component to be used by plugins.

issue resolves: #74

Example of usage:
opensearch-project/OpenSearch-Dashboards@25d7056
opensearch-project/alerting-dashboards-plugin#852

Issues Resolved

List any issues this PR will resolve, e.g. Closes [...].

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (0de2c9b) 95.63% compared to head (57b12b2) 87.98%.
Report is 1 commits behind head on main.

❗ Current head 57b12b2 differs from pull request most recent head bb72aff. Consider uploading reports for the commit bb72aff to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #53      +/-   ##
==========================================
- Coverage   95.63%   87.98%   -7.66%     
==========================================
  Files          48       52       +4     
  Lines        1261     1415     +154     
  Branches      312      346      +34     
==========================================
+ Hits         1206     1245      +39     
- Misses         53      168     +115     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ruanyl]

Q: Why render children again in popover title?

[kavilla]

i can sanitize this as the HTML is still coming through but I believe it was to the original UX suggestion. but it has been a while.

cc: @opensearch-project/opensearch-ux

[ruanyl]

I see, I was thinking the children could be something else other than a simple text node, if that's the case, the popover may look a bit strange?

[kavilla]

yeah. have updated it. also i think there were mocks at one point that add visualizations so its prolly a little bit over kill with the updated mocks i have modify it a bit

[kavilla]

here is out it currently looks. still not in its final form but without the children:

default:

hover:

clicked:

still need to keep improving it.

[ruanyl]

Just thinking if that's a good idea to implement Palantir as a generic component/service in OSD core? Instead of having core plugins or other plugins to depend on dashboards-assistant which doesn't sound optimum to me. Also having it in dashboards-assistant to serve a specific use case makes it hard to extend, as assistant might NOT be the only use case(Maybe a bit over thinking?).

Currently, the only part that makes Palantir component "assistant-specific" is the EuiPopoverFooter section which renders the action(s) to execute. I can move Palantir to OSD core and let the plugins to register the footer actions, here are some quick dummy code:

interface ActionConfig {
  type: string
  render: (palantirInput: PalantirInput, onSubmit: () => void) => React.ReactNode
}

type ActionListener = (palantirInput: PalantirInput) => void

// PalantirService in core
class PalantirService {
  actions = new Map<string, ActionConfig>
  handlers = new Set<ActionListener>()

  registerAction(actionConfig: ActionConfig) {
    this.actions.set(actionConfig.type, actionConfig)
  }

  addActionHandler(listener: ActionListener) {
    this.handlers.add(listener)
  }

  removeActionHandler(listener: ActionListener) {
    this.handlers.delete(listener)
  }

  handlePalantir(palantirInput: PalantirInput) {
    this.handlers.forEach(fn => fn(palantirInput))
  }
}

Then the assistant plugin register an action

core.palantirService.registerAction({
  type: 'assistant',
  render: (palantirInput, onSubmit) =>
    <>
      <EuiText size="xs">Continue in chat</EuiText>
      <EuiBadge
        color="hollow"
        iconType="chatRight"
        iconSide="left"
        onClick={onSubmit}
        onClickAriaLabel="Click for suggestion"
      >
        {palantirInput.suggestion}
      </EuiBadge>
    </>
})

Move the current Palantir component to core and change the EuiPopoverFooter to:

      <EuiPopoverFooter>
      {palantirService.actions.get(targetAction)?.render(palantirInput, () => onSubmitClick(palantirInput))}
      </EuiPopoverFooter>

And this is how Palantir will be used, targetAction will be specified so that Palantir know what action to display

<Palantir targetAction="assistant" title="xx" input={input}><WhateverComponent /></Palantir>

And assistant plugin handle the action:

  useEffect(() => {
    const handleSuggestion = (event: { suggestion: string }) => {
      // open chat window
      setFlyoutVisible(true);
      // start a new chat
      props.assistantActions.loadChat();
      // send message
      props.assistantActions.send({
        type: 'input',
        contentType: 'text',
        content: event.suggestion,
        context: { appId },
      });
    };
    core.palantirService.addActionHandler(handleSuggestion);
    return () => {
      core.palantirService.removeActionHandler(handleSuggestion);
    };
  }, []);

[kavilla]

i do like the way you think I was original planning on that path but thinking how far do we want to go.

there is a lot of existing services that are available within core OSD but are not used since they require proper wiring up.

i think eventual idea here would be to house this service and component within this plugin for the sake avoiding any breaking changes or issues within core OSD as this is still experimental. once enough feedback has been collected and the component is in its final state. then the core structure of this component can be placed into core OSD (and probably OUI). To which then this plugin then extends that core functionality of which you have mocked up and then if plugin developers decide that they want to hook up their features we can provide a guide but if they want to use a default functionality then they can just keep to using this plugin.

thoughts?

cc: @lezzago

[ruanyl]

Totally understand your concern, I believe we do want the service we added to core to be stable and to serve more general use cases instead of specific one.

Just one question came in to my mind: if OSD core or other plugins which import Palantir component from dashboards-assistant, will that break the build process when dashboards-assistant is not in the plugins folder?

[kavilla]

Totally understand your concern, I believe we do want the service we added to core to be stable and to serve more general use cases instead of specific one.

Totally. It would make it easier in some ways. Also we give us time to create a provider for the React context so that externally we can call certain functions from the assistant.

Just one question came in to my mind: if OSD core or other plugins which import Palantir component from dashboards-assistant, will that break the build process when dashboards-assistant is not in the plugins folder?

Great question. So here's an example: https://github.com/opensearch-project/alerting-dashboards-plugin/pull/852/files there is a conditional there for actually using the component. and likely my fast follow will be handling the importing from a non existing file. probably an alias to trick the compiler

[wanglam]

LGTM