Share modal re-architecture by eokoneyo · Pull Request #211665 · elastic/kibana

eokoneyo · 2025-02-18T22:59:55Z

Summary

This PR attempts to rework the internals for how the share plugin works, and brings with it a slight modification to how configs are registered to the share plugin, with this PR the share plugin now defines the following share types i.e. links, embeds and integrations. As such native implementations (i.e. copy link and embed) provided by sharedUX remain internal to the share plugin.

One might then ask what happens to the existing export functionality provided by the reporting plugin, in this PR the export functionality is now modelled as an integration that's simply grouped as an export, see the type definition for the Export type. Accompanying this change, a new method has been introduced registerShareIntegration that's similar to the previous method register, with a slight difference, in that now registered integrations can be scoped to a specific object type like so.

share.registerShareIntegration('lens', {
	...
	config: () => ({
		someValue: 'This integration value can only be retrieved within the lens objectType scope'
	})
})

The expected return type for config is defined by the user, as such the export integration type defines it's own expected type that suits the current implementation of the share modal.

Furthermore there's been a clean up with the config options that typically would be passed to the toggleShareMenu method, properties that are specific to a specific share type are now expected to be provided within the config property for that specific share type.

How to test

This change is transparent to the user with all share functionality working as should, regardless respective teams should verify that all share behaviour work as expected.

eokoneyo · 2025-03-05T10:19:39Z

/ci

eokoneyo · 2025-03-05T10:49:19Z

/ci

eokoneyo · 2025-03-07T12:20:34Z

/ci

eokoneyo · 2025-03-07T15:38:11Z

/ci

eokoneyo · 2025-03-07T16:33:49Z

/ci

eokoneyo · 2025-03-10T08:31:03Z

/ci

eokoneyo · 2025-03-18T10:58:52Z

/ci

pmuellr

LGTM. Tested generating CSV, PNG, PDF, PDF for printing, all worked fine.

I noticed a change to a param used to generate the "search source", so thought I would comment on it. Seems like it could change the time frame of the CSV report

pmuellr · 2025-04-22T20:45:52Z

-    const capabilityHasCsvReporting = application.capabilities.discover_v2?.generateCsv === true;
+    const { reportType, decoratedJobParams } = getSearchCsvJobParams({
+      apiClient,
+      searchModeParams: getSearchModeParams(true),


Is it intentional to change the parm for getSearchModeParams() from false previously, to true in this PR? It looks like it changes the absoluteTime param of getSearchSource()

it was... however I'd be reverting to the previous implementation because there's another body of work that actually takes care of providing the user a choice on wether they'd like to use absolute or relative time when choosing to share, instead of forcing it.

eokoneyo · 2025-04-23T08:30:49Z

@elasticmachine merge upstream

elasticmachine · 2025-04-23T11:19:31Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: 021e2ec

Failed CI Steps

FTR Configs #114

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`	73	53	-20

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`dashboard`	550.2KB	550.2KB	-73.0B
`discover`	958.6KB	958.6KB	+15.0B
`lens`	1.4MB	1.4MB	-56.0B
`visualizations`	340.2KB	340.2KB	-14.0B
total			-128.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
`share`	16	15	-1

Page load bundle

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

id	before	after	diff
`lens`	57.7KB	57.8KB	+73.0B
`reporting`	48.9KB	49.4KB	+541.0B
`share`	54.2KB	56.1KB	+1.9KB
total			+2.5KB

Unknown metric groups

API count

id	before	after	diff
`share`	136	118	-18

References to deprecated APIs

id	before	after	diff
`@kbn/reporting-public`	1	2	+1
`discover`	8	7	-1
`lens`	77	76	-1
total			-1

History

💚 Build #294530 succeeded 2c0e85c
💚 Build #294109 succeeded 91c7dae
💔 Build #292570 failed 468d512
💛 Build #290520 was flaky 6974134
💚 Build #289924 succeeded 9918a5d
💚 Build #289321 succeeded 9ad9a59

cc @eokoneyo

## Summary This PR attempts to rework the internals for how the share plugin works, and brings with it a slight modification to how configs are registered to the share plugin, with this PR the share plugin now defines the following share types i.e. `links`, `embeds` and `integrations`. As such native implementations (i.e. copy link and embed) provided by sharedUX remain internal to the share plugin. One might then ask what happens to the existing export functionality provided by the reporting plugin, in this PR the export functionality is now modelled as an integration that's simply grouped as an export, see the type definition for the Export type. Accompanying this change, a new method has been introduced `registerShareIntegration` that's similar to the previous method `register`, with a slight difference, in that now registered integrations can be scoped to a specific object type like so. ```ts share.registerShareIntegration('lens', { ... config: () => ({ someValue: 'This integration value can only be retrieved within the lens objectType scope' }) }) ``` The expected return type for config is defined by the user, as such the export integration type defines it's own expected type that suits the current implementation of the share modal.  Furthermore there's been a clean up with the config options that typically would be passed to the `toggleShareMenu` method, properties that are specific to a specific share type are now expected to be provided within the config property for that specific share type. ## How to test - This change is transparent to the user with all share functionality working as should, regardless respective teams should verify that all share behaviour work as expected.  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

## Summary Closes #205805 This PR extracts the share export functionality into a standalone triggered UI action, and builds mostly off of the work that's been done in #211665 as such any share integration type that's registered under the groupId `export` will show up within the afore mentioned standalone export type. Registering a new export type would happen like so; ```js share.registerShareIntegration({ groupId: 'export', ... config: () => ({ ... }), prerequisiteCheck({ license, capabilities, objectType }) { // The prerequisiteCheck callback will get passed the license, app capabilities and the objectType // of the current caller, this can then be used to determine if this integration should be available, // returning false in here disables the integration, } }) ``` *P.S.* This registration can also be scoped to a particular object type (i.e. lens, dashboard etc.) if said integration is intended to only be available for only a particular object type. ## Visuals for new export experience #### _visualize_ ##### (_lens_) <img width="768" alt="Screenshot 2025-04-24 at 10 53 25" src="https://github.com/user-attachments/assets/31966ded-b1f7-417e-840e-4596b310d6bc" /> ##### (_others_) <img width="1720" alt="Screenshot 2025-04-25 at 09 04 50" src="https://github.com/user-attachments/assets/8b675974-9a4b-4dcc-9aca-77cea5a25654" /> #### _dashboard_ ##### _(user with all reporting permissions)_ <img width="640" alt="Screenshot 2025-04-24 at 10 53 40" src="https://github.com/user-attachments/assets/d16da148-3c25-4a58-a847-d4d5a3736106" /> ##### _(user with no pdf, png, csv privileges doesn't have the export button visible)_ <img width="1728" alt="Screenshot 2025-05-02 at 13 11 21" src="https://github.com/user-attachments/assets/e47426fb-db5b-4c2a-bee5-557fefbb40ec" /> #### _discover_ <img width="626" alt="Screenshot 2025-04-04 at 20 18 50" src="https://github.com/user-attachments/assets/f4bdd2a3-2527-4334-b253-7686e4131d87" /> <img width="1728" alt="Screenshot 2025-05-02 at 13 11 43" src="https://github.com/user-attachments/assets/9a6e7fa2-260d-4b68-a1ae-61c499849fb8" /> ### Test scenarios - Pull this PR and run it locally, or test in the provision environment linked to this PR. - Navigate to the dashboard, discover, and visualize app. The nav menu should display icon buttons for sharing and export. - Clicking the "Share" icon (up arrow) opens the familiar share modal without export. The "Export" icon (down arrow) opens a new popover with available options. - Export Functionality Test; - Single Export Option: When there's only one export option, the flyout opens automatically. - Disabled Reporting Features: Create a new role with reporting subPrivileges and test it by creating a user assigned to that role. Log in as the user, and the export popover should reflect the limited reporting features. - In the case where the current user has no registered integrations available to them, the export functionality will not be displayed  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

## Summary Closes elastic#205805 This PR extracts the share export functionality into a standalone triggered UI action, and builds mostly off of the work that's been done in elastic#211665 as such any share integration type that's registered under the groupId `export` will show up within the afore mentioned standalone export type. Registering a new export type would happen like so; ```js share.registerShareIntegration({ groupId: 'export', ... config: () => ({ ... }), prerequisiteCheck({ license, capabilities, objectType }) { // The prerequisiteCheck callback will get passed the license, app capabilities and the objectType // of the current caller, this can then be used to determine if this integration should be available, // returning false in here disables the integration, } }) ``` *P.S.* This registration can also be scoped to a particular object type (i.e. lens, dashboard etc.) if said integration is intended to only be available for only a particular object type. ## Visuals for new export experience #### _visualize_ ##### (_lens_) <img width="768" alt="Screenshot 2025-04-24 at 10 53 25" src="https://github.com/user-attachments/assets/31966ded-b1f7-417e-840e-4596b310d6bc" /> ##### (_others_) <img width="1720" alt="Screenshot 2025-04-25 at 09 04 50" src="https://github.com/user-attachments/assets/8b675974-9a4b-4dcc-9aca-77cea5a25654" /> #### _dashboard_ ##### _(user with all reporting permissions)_ <img width="640" alt="Screenshot 2025-04-24 at 10 53 40" src="https://github.com/user-attachments/assets/d16da148-3c25-4a58-a847-d4d5a3736106" /> ##### _(user with no pdf, png, csv privileges doesn't have the export button visible)_ <img width="1728" alt="Screenshot 2025-05-02 at 13 11 21" src="https://github.com/user-attachments/assets/e47426fb-db5b-4c2a-bee5-557fefbb40ec" /> #### _discover_ <img width="626" alt="Screenshot 2025-04-04 at 20 18 50" src="https://github.com/user-attachments/assets/f4bdd2a3-2527-4334-b253-7686e4131d87" /> <img width="1728" alt="Screenshot 2025-05-02 at 13 11 43" src="https://github.com/user-attachments/assets/9a6e7fa2-260d-4b68-a1ae-61c499849fb8" /> ### Test scenarios - Pull this PR and run it locally, or test in the provision environment linked to this PR. - Navigate to the dashboard, discover, and visualize app. The nav menu should display icon buttons for sharing and export. - Clicking the "Share" icon (up arrow) opens the familiar share modal without export. The "Export" icon (down arrow) opens a new popover with available options. - Export Functionality Test; - Single Export Option: When there's only one export option, the flyout opens automatically. - Disabled Reporting Features: Create a new role with reporting subPrivileges and test it by creating a user assigned to that role. Log in as the user, and the export popover should reflect the limited reporting features. - In the case where the current user has no registered integrations available to them, the export functionality will not be displayed  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

eokoneyo · 2025-06-24T18:25:21Z

💚 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

## Summary This PR attempts to rework the internals for how the share plugin works, and brings with it a slight modification to how configs are registered to the share plugin, with this PR the share plugin now defines the following share types i.e. `links`, `embeds` and `integrations`. As such native implementations (i.e. copy link and embed) provided by sharedUX remain internal to the share plugin. One might then ask what happens to the existing export functionality provided by the reporting plugin, in this PR the export functionality is now modelled as an integration that's simply grouped as an export, see the type definition for the Export type. Accompanying this change, a new method has been introduced `registerShareIntegration` that's similar to the previous method `register`, with a slight difference, in that now registered integrations can be scoped to a specific object type like so. ```ts share.registerShareIntegration('lens', { ... config: () => ({ someValue: 'This integration value can only be retrieved within the lens objectType scope' }) }) ``` The expected return type for config is defined by the user, as such the export integration type defines it's own expected type that suits the current implementation of the share modal.  Furthermore there's been a clean up with the config options that typically would be passed to the `toggleShareMenu` method, properties that are specific to a specific share type are now expected to be provided within the config property for that specific share type. ## How to test - This change is transparent to the user with all share functionality working as should, regardless respective teams should verify that all share behaviour work as expected.  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit 37afbb5) # Conflicts: # src/platform/packages/private/kbn-reporting/public/share/share_context_menu/register_csv_modal_reporting.tsx # src/platform/plugins/shared/dashboard/public/dashboard_app/top_nav/share/show_share_modal.tsx # src/platform/plugins/shared/discover/public/application/main/components/top_nav/app_menu_actions/get_share.tsx # src/platform/plugins/shared/share/public/components/context/index.tsx # src/platform/plugins/shared/share/public/components/share_tabs.test.tsx # src/platform/plugins/shared/share/public/components/tabs/link/link_content.tsx # src/platform/plugins/shared/share/public/services/share_menu_manager.tsx # src/platform/plugins/shared/share/public/types.ts

This PR attempts to rework the internals for how the share plugin works, and brings with it a slight modification to how configs are registered to the share plugin, with this PR the share plugin now defines the following share types i.e. `links`, `embeds` and `integrations`. As such native implementations (i.e. copy link and embed) provided by sharedUX remain internal to the share plugin. One might then ask what happens to the existing export functionality provided by the reporting plugin, in this PR the export functionality is now modelled as an integration that's simply grouped as an export, see the type definition for the Export type. Accompanying this change, a new method has been introduced `registerShareIntegration` that's similar to the previous method `register`, with a slight difference, in that now registered integrations can be scoped to a specific object type like so. ```ts share.registerShareIntegration('lens', { ... config: () => ({ someValue: 'This integration value can only be retrieved within the lens objectType scope' }) }) ``` The expected return type for config is defined by the user, as such the export integration type defines it's own expected type that suits the current implementation of the share modal.  Furthermore there's been a clean up with the config options that typically would be passed to the `toggleShareMenu` method, properties that are specific to a specific share type are now expected to be provided within the config property for that specific share type. - This change is transparent to the user with all share functionality working as should, regardless respective teams should verify that all share behaviour work as expected.  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit 37afbb5)

# Backport This will backport the following commits from `main` to `8.19`: - [Share modal re-architecture (#211665)](#211665)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

## Summary Closes elastic#205805 This PR extracts the share export functionality into a standalone triggered UI action, and builds mostly off of the work that's been done in elastic#211665 as such any share integration type that's registered under the groupId `export` will show up within the afore mentioned standalone export type. Registering a new export type would happen like so; ```js share.registerShareIntegration({ groupId: 'export', ... config: () => ({ ... }), prerequisiteCheck({ license, capabilities, objectType }) { // The prerequisiteCheck callback will get passed the license, app capabilities and the objectType // of the current caller, this can then be used to determine if this integration should be available, // returning false in here disables the integration, } }) ``` *P.S.* This registration can also be scoped to a particular object type (i.e. lens, dashboard etc.) if said integration is intended to only be available for only a particular object type. ## Visuals for new export experience #### _visualize_ ##### (_lens_) <img width="768" alt="Screenshot 2025-04-24 at 10 53 25" src="https://github.com/user-attachments/assets/31966ded-b1f7-417e-840e-4596b310d6bc" /> ##### (_others_) <img width="1720" alt="Screenshot 2025-04-25 at 09 04 50" src="https://github.com/user-attachments/assets/8b675974-9a4b-4dcc-9aca-77cea5a25654" /> #### _dashboard_ ##### _(user with all reporting permissions)_ <img width="640" alt="Screenshot 2025-04-24 at 10 53 40" src="https://github.com/user-attachments/assets/d16da148-3c25-4a58-a847-d4d5a3736106" /> ##### _(user with no pdf, png, csv privileges doesn't have the export button visible)_ <img width="1728" alt="Screenshot 2025-05-02 at 13 11 21" src="https://github.com/user-attachments/assets/e47426fb-db5b-4c2a-bee5-557fefbb40ec" /> #### _discover_ <img width="626" alt="Screenshot 2025-04-04 at 20 18 50" src="https://github.com/user-attachments/assets/f4bdd2a3-2527-4334-b253-7686e4131d87" /> <img width="1728" alt="Screenshot 2025-05-02 at 13 11 43" src="https://github.com/user-attachments/assets/9a6e7fa2-260d-4b68-a1ae-61c499849fb8" /> ### Test scenarios - Pull this PR and run it locally, or test in the provision environment linked to this PR. - Navigate to the dashboard, discover, and visualize app. The nav menu should display icon buttons for sharing and export. - Clicking the "Share" icon (up arrow) opens the familiar share modal without export. The "Export" icon (down arrow) opens a new popover with available options. - Export Functionality Test; - Single Export Option: When there's only one export option, the flyout opens automatically. - Disabled Reporting Features: Create a new role with reporting subPrivileges and test it by creating a user assigned to that role. Log in as the user, and the export popover should reflect the limited reporting features. - In the case where the current user has no registered integrations available to them, the export functionality will not be displayed  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit a887cd6) # Conflicts: # src/platform/packages/private/kbn-reporting/public/share/share_context_menu/index.ts # src/platform/packages/private/kbn-reporting/public/share/share_context_menu/register_csv_modal_reporting.tsx # src/platform/packages/private/kbn-reporting/public/share/share_context_menu/register_pdf_png_modal_reporting.tsx # src/platform/plugins/shared/discover/public/application/main/components/top_nav/app_menu_actions/get_share.tsx # src/platform/plugins/shared/share/kibana.jsonc # src/platform/plugins/shared/share/public/services/share_menu_manager.tsx # src/platform/plugins/shared/share/public/types.ts # src/platform/plugins/shared/share/tsconfig.json # src/platform/plugins/shared/visualizations/public/visualize_app/utils/get_top_nav_config.tsx # x-pack/platform/plugins/private/reporting/public/plugin.ts # x-pack/platform/plugins/private/translations/translations/fr-FR.json # x-pack/platform/plugins/private/translations/translations/ja-JP.json # x-pack/platform/plugins/private/translations/translations/zh-CN.json # x-pack/platform/plugins/shared/lens/public/app_plugin/lens_top_nav.tsx

Closes elastic#205805 This PR extracts the share export functionality into a standalone triggered UI action, and builds mostly off of the work that's been done in elastic#211665 as such any share integration type that's registered under the groupId `export` will show up within the afore mentioned standalone export type. Registering a new export type would happen like so; ```js share.registerShareIntegration({ groupId: 'export', ... config: () => ({ ... }), prerequisiteCheck({ license, capabilities, objectType }) { // The prerequisiteCheck callback will get passed the license, app capabilities and the objectType // of the current caller, this can then be used to determine if this integration should be available, // returning false in here disables the integration, } }) ``` *P.S.* This registration can also be scoped to a particular object type (i.e. lens, dashboard etc.) if said integration is intended to only be available for only a particular object type. <img width="768" alt="Screenshot 2025-04-24 at 10 53 25" src="https://github.com/user-attachments/assets/31966ded-b1f7-417e-840e-4596b310d6bc" /> <img width="1720" alt="Screenshot 2025-04-25 at 09 04 50" src="https://github.com/user-attachments/assets/8b675974-9a4b-4dcc-9aca-77cea5a25654" /> <img width="640" alt="Screenshot 2025-04-24 at 10 53 40" src="https://github.com/user-attachments/assets/d16da148-3c25-4a58-a847-d4d5a3736106" /> button visible)_ <img width="1728" alt="Screenshot 2025-05-02 at 13 11 21" src="https://github.com/user-attachments/assets/e47426fb-db5b-4c2a-bee5-557fefbb40ec" /> <img width="626" alt="Screenshot 2025-04-04 at 20 18 50" src="https://github.com/user-attachments/assets/f4bdd2a3-2527-4334-b253-7686e4131d87" /> <img width="1728" alt="Screenshot 2025-05-02 at 13 11 43" src="https://github.com/user-attachments/assets/9a6e7fa2-260d-4b68-a1ae-61c499849fb8" /> - Pull this PR and run it locally, or test in the provision environment linked to this PR. - Navigate to the dashboard, discover, and visualize app. The nav menu should display icon buttons for sharing and export. - Clicking the "Share" icon (up arrow) opens the familiar share modal without export. The "Export" icon (down arrow) opens a new popover with available options. - Export Functionality Test; - Single Export Option: When there's only one export option, the flyout opens automatically. - Disabled Reporting Features: Create a new role with reporting subPrivileges and test it by creating a user assigned to that role. Log in as the user, and the export popover should reflect the limited reporting features. - In the case where the current user has no registered integrations available to them, the export functionality will not be displayed  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit a887cd6)

# Backport This will backport the following commits from `main` to `8.19`: - [Separate export menu from share (#217109)](#217109)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

eokoneyo added the Team:SharedUX Platform AppEx-SharedUX (formerly Global Experience) t// label Feb 18, 2025

eokoneyo force-pushed the feat/share-rearchitecture branch from 1db5b72 to d4162c9 Compare February 18, 2025 23:00

eokoneyo changed the title ~~[] Share modal re-work~~ Share modal re-architecture Feb 18, 2025

eokoneyo changed the title ~~Share modal re-architecture~~ [WiP] Share modal re-architecture Feb 19, 2025

eokoneyo force-pushed the feat/share-rearchitecture branch 8 times, most recently from 333f34a to cc0566a Compare February 21, 2025 16:28

eokoneyo self-assigned this Feb 21, 2025

eokoneyo added the release_note:skip Skip the PR/issue when compiling release notes label Feb 21, 2025

eokoneyo force-pushed the feat/share-rearchitecture branch 2 times, most recently from 75afcd9 to 715606a Compare March 3, 2025 11:04

eokoneyo force-pushed the feat/share-rearchitecture branch from fdcb6ed to 3a0a171 Compare March 7, 2025 12:20

eokoneyo force-pushed the feat/share-rearchitecture branch from 3a0a171 to 85b2418 Compare March 7, 2025 15:37

eokoneyo force-pushed the feat/share-rearchitecture branch from 85b2418 to 5fbdad0 Compare March 7, 2025 16:19

eokoneyo force-pushed the feat/share-rearchitecture branch 2 times, most recently from 0e31025 to 51eb479 Compare March 10, 2025 08:30

eokoneyo force-pushed the feat/share-rearchitecture branch from 51eb479 to 74ea7d7 Compare March 18, 2025 09:47

eokoneyo force-pushed the feat/share-rearchitecture branch from 74ea7d7 to d72488b Compare March 19, 2025 12:45

Merge branch 'main' into feat/share-rearchitecture

2c0e85c

pmuellr approved these changes Apr 22, 2025

View reviewed changes

attend to PR comment

0442b8d

Merge branch 'main' into feat/share-rearchitecture

021e2ec

eokoneyo mentioned this pull request Apr 23, 2025

[Share] Review all the warning text for sharing modal across apps it's been used with #218919

Closed

eokoneyo merged commit 37afbb5 into elastic:main Apr 23, 2025
9 checks passed

eokoneyo deleted the feat/share-rearchitecture branch April 23, 2025 11:34

kibanamachine added the v9.1.0 label Apr 23, 2025

This was referenced May 2, 2025

[Share Context Modal Redesign] Refactor delegatedShareUrlHandler to handle Promise results #182681

Closed

[Share] Support a lazy evaluation for shareableUrl parameter #153936

Closed

[Epic] Sharing Modal Architecture #195313

Closed

eokoneyo mentioned this pull request Jun 24, 2025

[8.19] Share modal re-architecture (#211665) #225143

Merged

kibanamachine added the v8.19.0 label Jun 25, 2025

Conversation

eokoneyo commented Feb 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

How to test

Uh oh!

eokoneyo commented Mar 5, 2025

Uh oh!

eokoneyo commented Mar 5, 2025

Uh oh!

eokoneyo commented Mar 7, 2025

Uh oh!

eokoneyo commented Mar 7, 2025

Uh oh!

eokoneyo commented Mar 7, 2025

Uh oh!

eokoneyo commented Mar 10, 2025

Uh oh!

eokoneyo commented Mar 18, 2025

Uh oh!

pmuellr left a comment

Choose a reason for hiding this comment

Uh oh!

pmuellr Apr 22, 2025

Choose a reason for hiding this comment

Uh oh!

eokoneyo Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

eokoneyo commented Apr 23, 2025

Uh oh!

elasticmachine commented Apr 23, 2025

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

Public APIs missing comments

Async chunks

Public APIs missing exports

Page load bundle

API count

References to deprecated APIs

History

Uh oh!

Uh oh!

eokoneyo commented Jun 24, 2025

💚 All backports created successfully

Questions ?

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

eokoneyo commented Feb 18, 2025 •

edited

Loading