Add export derivative integration type

[eokoneyo]

This PR adds a new share integration type (i.e. the exportDerivative). This integration is a special one that is only to be used in a scenario where a team would like to offer some extra functionality that depends on the availability of some export integration. Specifically because of the way this has been coupled to be presented to the user the exportDerivative type integration would only be displayed to the user when at least one export integration exists.

This particular integration is also much more flexible, in that it only accepts a label to denote what should be rendered to the user, and a freeform component that will be rendered into the flyout that will in turn open when the provided label is clicked.

One might configure an integration for this like so;

      share.registerShareIntegration<ExportShareDerivatives>({
        id: 'scheduledReporting',
        groupId: 'exportDerivatives',
        config: () => ({
          label: ({ openFlyout }) =>
            React.createElement(
              EuiButton,
              { iconType: 'calendar', onClick: openFlyout },
              'schedule report'
            ),
          flyoutContent: ({ closeFlyout , flyoutRef }) => {
            return React.createElement(
              EuiButton,
              {
                iconType: 'calendar',
              },
              'Click me'
            );
          },
        }),
      });

The following config would produce the following experience;

[eokoneyo]

@elasticmachine merge upstream

[eokoneyo]

/ci

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[Dosant]

Is there any good reason we need to manage the flyout ourselves?
Just a thought: maybe it would be simpler for us to allow rendering whatever they want, and when the user clicks, they can open a flyout, a modal, or take some action right away.

[Dosant]

imo, If keeping something like this, then I'd suggest the api using render props. Imo clearer to use (explicit how label becomes clickable) and easier for us to implement (no cloneElement, for example)

eport interface ExportShareDerivatives
  extends ShareIntegration<{
    label: (props: {openFlyout}) => ReactNode
    toolTipContent?: ReactNode;
    flyoutContent: (props: { closeFlyout}) => ReactNode

[eokoneyo]

Is there any good reason we need to manage the flyout ourselves? Just a thought: maybe it would be simpler for us to allow rendering whatever they want, and when the user clicks, they can open a flyout, a modal, or take some action right away.

It's really part of the desire to align what the export experience is, so it's predictable in a way

[eokoneyo]

imo, If keeping something like this, then I'd suggest the api using render props. Imo clearer to use (explicit how label becomes clickable) and easier for us to implement (no cloneElement, for example)

eport interface ExportShareDerivatives
  extends ShareIntegration<{
    label: (props: {openFlyout}) => ReactNode
    toolTipContent?: ReactNode;
    flyoutContent: (props: { closeFlyout}) => ReactNode

I think this is a fair point, I like the modification you proposed definitely hands-off even more control. Thanks Anton!

[Dosant]

I also thought that a derivative is an unusual name, have you considered exportExtension, which seems something more common to me?

[Copilot]

Pull Request Overview

This PR adds a new export derivative integration type, expanding the share integration functionality and adjusting several context and component implementations to support this new variant.

• Introduces the ExportShareDerivatives interface and related types.
• Updates UI components to support both export and export derivative integrations.
• Refactors context hook usage across components and tests.

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
x-pack/test/functional/page_objects/lens_page.ts	Updates test to pass a callback to clickPopoverItem.
src/platform/test/functional/page_objects/export_page.ts	Modifies clickPopoverItem to accept an optional opener callback.
src/platform/plugins/shared/share/public/types.ts	Adds the ExportShareDerivatives interface and updates type unions.
src/platform/plugins/shared/share/public/index.ts	Exports the new ExportShareDerivatives type.
src/platform/plugins/shared/share/public/components/tabs/link/index.tsx	Renames context hook usage for clarity.
src/platform/plugins/shared/share/public/components/tabs/embed/index.tsx	Renames context hook usage for clarity.
src/platform/plugins/shared/share/public/components/share_tabs.tsx	Replaces ShareMenuProvider with ShareProvider.
src/platform/plugins/shared/share/public/components/share_tabs.test.tsx	Updates tests to reflect the new context provider naming.
src/platform/plugins/shared/share/public/components/export_popover/export_popover.tsx	Refactors export popover implementation to include support for export derivatives.
src/platform/plugins/shared/share/public/components/context/index.tsx	Renames context and updates filtering logic in the hook.
src/platform/plugins/shared/share/public/components/context/index.test.tsx	Updates tests to use the revised context hook.
src/platform/packages/private/kbn-reporting/public/share/share_context_menu/register_csv_modal_reporting.tsx	Adds an icon property for CSV export integration.

Comments suppressed due to low confidence (2)

x-pack/test/functional/page_objects/lens_page.ts:2010

• Verify that passing the clickExportButton callback as a parameter to clickPopoverItem is consistent with its usage elsewhere and meets the intended testing behavior.

await exports.clickPopoverItem('CSV', this.clickExportButton.bind(this));

src/platform/plugins/shared/share/public/components/context/index.tsx:58

• Review the filtering logic here: using (groupId ?? item?.groupId) means that when groupId is undefined, the condition always holds true. Confirm that this behavior is intentional.

(item) => item.shareType === shareType && item?.groupId === (groupId ?? item?.groupId)

[Copilot]

Consider explicitly verifying that selectedMenuItemMeta is defined before accessing its properties, rather than using a non-null assertion, to safeguard against potential runtime errors.

Suggested change

	{selectedMenuItemMeta!.group === 'export' ? (
	{selectedMenuItemMeta && selectedMenuItemMeta.group === 'export' ? (

[eokoneyo]

I also thought that a derivative is an unusual name, have you considered exportExtension, which seems something more common to me?

I'd chosen derivative to somewhat denote for this specific integration that it requires at least one active export integration for it be surfaced and especially that it's a UI construct rather it being a implicit implementation detail. I worry exportExtension doesn't communicate this, wdyt?

[umbopepato]

Thanks @eokoneyo for implementing this new extension point so quickly!
LGTM (considering the popovers z-index issue solved with EUI's recommendation)

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 13ba1ee

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
share	53	55	+2

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
reporting	50.5KB	50.5KB	+17.0B
share	50.6KB	51.7KB	+1.1KB
total			+1.1KB

Unknown metric groups

API count

id	before	after	diff
share	119	121	+2

History

• 💚 Build #308770 succeeded 720f86b
• 💚 Build #308694 succeeded 75b6097
• 💚 Build #308608 succeeded cce319f
• 💔 Build #308597 failed 0e05f50
• 💔 Build #308596 failed 86da0f8
• 💔 Build #308555 failed 5a7fe2d

cc @eokoneyo

[eokoneyo]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation