Deprecate kibana_react RedirectAppLinks in favor of shared_ux RedirectAppLinks

[rshen91]

Summary

This PR is intended to alert teams using the RedirectAppLinks component of the deprecation of the previous implementation. The RedirectAppLinks can now be imported from the shared ux package.

• Instead of consuming the entire application, the refactored RedirectAppLinks component requires:

currentAppId$: Observable<string | undefined>;
navigateToUrl(url: string): Promise<void>;

This PR just adds deprecation labels to the current implementations of RedirectAppLinks.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[flash1293]

VisEditors changes LGTM, just adding deprecated markers

[lukeelmers]

I don't think all of these comments are necessary: If you add @deprecated to the JSDoc comments where RedirectAppLinks is defined, as well as a @removeBy version, then the deprecation and all of its usages will automatically be tracked in the deprecated API docs (internal link).

Also, many IDEs will automatically indicate that the API in use is deprecated (vscode example below), so I don't think the comments are adding much.

[lukeelmers]

@rshen91 Just to clarify, I was recommending the following:

• Adding a deprecated (and optionally removeBy) flag where RedirectAppLinks is defined

 * @remarks
 * It is recommended to use the component at the highest possible level of the component tree that would
 * require to handle the links. A good practice is to consider it as a context provider and to use it
 * at the root level of an application or of the page that require the feature.
+* 
+* @deprecated
+* @removeBy 8.3 // or whatever
 */

• Removing all of these comments (not just from this file, but from the whole PR)

-/** @deprecated Use `RedirectAppLinks` from `@kbn/shared-ux-components */

This way you don't need any CODEOWNERS reviews, and we can use our existing docs tooling to determine where deprecated APIs are in use and track that they are removed on time. (Or, as Julia suggests, it might save y'all a lot of wrangling to just make those changes in this PR directly, since it's only used in a few places).

[rshen91]

ah ok I think Im following thank you

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

LGTM, out of curiosity, is there any risk of just updating the imports in this pr? It doesn't look like more effort than adding the deprecation comment.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: b55adca
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

Unknown metric groups

References to deprecated APIs

id	before	after	diff
apm	29	32	+3
cloudSecurityPosture	0	3	+3
dataEnhanced	49	55	+6
esUiShared	0	3	+3
fleet	5	20	+15
home	0	6	+6
indexLifecycleManagement	1	5	+4
infra	11	14	+3
kibanaOverview	1	12	+11
lens	15	18	+3
ml	12	18	+6
observability	0	3	+3
savedObjectsManagement	2	8	+6
spaces	9	12	+3
upgradeAssistant	8	12	+4
uptime	26	32	+6
ux	20	23	+3
visualizations	14	17	+3
total			+91

History

• 💚 Build #33060 succeeded 843fc9b
• 💚 Build #32389 succeeded 2f7fe26
• 💔 Build #32290 failed a1f4c47

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @rshen91

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 128178 or prevent reminders by adding the backport:skip label.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 128178 or prevent reminders by adding the backport:skip label.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 128178 or prevent reminders by adding the backport:skip label.