generated from redhat-developer/new-project-template
-
Notifications
You must be signed in to change notification settings - Fork 58
RHIDP-5152: Add Frontend Plugn Wiring Section #1259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
pabel-rh
merged 6 commits into
redhat-developer:main
from
jmagak:RHIDP-5152-Add-Frontend-Plugin-Wiring-section-to-Installing-and-viewing-plugins
Aug 18, 2025
Merged
Changes from 5 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
9f703d0
Add frontend plugn wiring section
invalid-email-address ec20eb8
Add frontend plugn wiring section
invalid-email-address be15fef
Add frontend plugn wiring section
invalid-email-address 3e4e1fd
Add frontend plugn wiring section
invalid-email-address fa74239
Add frontend plugn wiring section
invalid-email-address 3b1d320
Add frontend plugn wiring section
invalid-email-address File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
49 changes: 49 additions & 0 deletions
49
assemblies/dynamic-plugins/assembly-front-end-plugin-wiring.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,49 @@ | ||
| [id="assembly-front-end-plugin-wiring.adoc_{context}"] | ||
| = Front-end plugin wiring | ||
| :context: assembly-front-end-plugin-wiring | ||
|
|
||
| You can configure front-end plugins to customize icons, integrate components at mount points, and provide or replace utility APIs. | ||
|
|
||
| // Extending the internal icon catalog | ||
| include::../modules/dynamic-plugins/proc-extending-internal-icon-catalog.adoc[leveloffset=+1] | ||
|
|
||
| // Defining dynamic routes for new plugin pages | ||
| include::../modules/dynamic-plugins/proc-defining-dynamic-routes-for-new-plugin-pages.adoc[leveloffset=+1] | ||
|
|
||
| // Customizing menu items in the sidebar navigation | ||
| include::../modules/dynamic-plugins/proc-customizing-sidebar-menu-items.adoc[leveloffset=+1] | ||
|
|
||
| // Bind to existing plugins | ||
| include::../modules/dynamic-plugins/proc-binding-to-existing-plugins.adoc[leveloffset=+1] | ||
|
|
||
| // Using mount points | ||
| include::../modules/dynamic-plugins/proc-using-mount-points.adoc[leveloffset=+1] | ||
|
|
||
| include::../modules/dynamic-plugins/proc-customizing-entity-page.adoc[leveloffset=+2] | ||
|
|
||
| include::../modules/dynamic-plugins/proc-adding-application-header.adoc[leveloffset=+2] | ||
|
|
||
| include::../modules/dynamic-plugins/proc-adding-application-listeners.adoc[leveloffset=+2] | ||
|
|
||
| include::../modules/dynamic-plugins/proc-adding-application-providers.adoc[leveloffset=+2] | ||
|
|
||
| // Customizing and extending entity tabs | ||
| include::../modules/dynamic-plugins/proc-customizing-and-extending-entity-tabs.adoc[leveloffset=+1] | ||
|
|
||
| // SignIn page | ||
| include::../modules/dynamic-plugins/con-using-custom-signinpage-component.adoc[leveloffset=+1] | ||
|
|
||
| // custom scaffolder extension | ||
| include::../modules/dynamic-plugins/con-providing-custom-scaffolder-field-extensions.adoc[leveloffset=+1] | ||
|
|
||
| // Provide additional Utility APIs | ||
| include::../modules/dynamic-plugins/proc-provide-additional-utility-apis.adoc[leveloffset=+1] | ||
|
|
||
| // Adding custom authentication provider settings | ||
| include::../modules/dynamic-plugins/proc-adding-custom-authentication-provider-settings.adoc[leveloffset=+1] | ||
|
|
||
| // Provide custom techdocs addons | ||
| include::../modules/dynamic-plugins/proc-provide-custom-techdocs-addons.adoc[leveloffset=+1] | ||
|
|
||
| // Customizing theme | ||
| include::../modules/dynamic-plugins/proc-customizing-theme.adoc[leveloffset=+1] | ||
26 changes: 26 additions & 0 deletions
26
modules/dynamic-plugins/con-providing-custom-scaffolder-field-extensions.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| [id="con-providing-custom-scaffolder-field-extensions.adoc_{context}"] | ||
| = Providing custom Scaffolder field extensions | ||
|
|
||
| The Scaffolder component in {product} ({product-very-short}) enables users to create software components using templates through a guided wizard. You can extend the functionality of the Scaffolder by providing custom form fields as dynamic plugins using the `scaffolderFieldExtensions` configuration. | ||
|
|
||
| Custom field extensions allow you to add specialized form fields that capture domain-specific data during the scaffolding process, such as environment selectors, input validations, or repository checks. | ||
|
|
||
| When you configure custom scaffolder field extensions: | ||
|
|
||
| * The dynamic plugin exposes the field extension component using `createScaffolderFieldExtension`. | ||
| * Each field extension requires a unique `importName` for registration. | ||
| * You register multiple field extensions by listing each in the configuration. | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| scaffolderFieldExtensions: | ||
| - importName: MyNewFieldExtension # References the exported scaffolder field extension component from your plugin | ||
| ---- | ||
|
|
||
| [NOTE] | ||
| ==== | ||
| The `module` field is optional and specifies which set of assets to access within the plugin. By default, the system uses the `PluginRoot` module, consistent with the `scalprum.exposedModules` key in the `package.json` file of your package. | ||
| ==== |
26 changes: 26 additions & 0 deletions
26
modules/dynamic-plugins/con-using-custom-signinpage-component.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| [id="con-using-custom-signinpage-component.adoc_{context}"] | ||
| = Using a custom SignInPage component | ||
|
|
||
| In {product} ({product-very-short}), the `SignInPage` component manages the authentication flow of the application. This component connects one or more authentication providers to the sign-in process. By default, {product-short} uses a static `SignInPage` that supports all built-in authentication providers. | ||
|
|
||
| When you configure a custom `SignInPage`: | ||
|
|
||
| * The system loads the specified `importName` component from your dynamic plugin. | ||
| * The component returns a configured `SignInPage` that connects the desired authentication provider factories. | ||
| * Only one `signInPage` is specified for the application at a time. | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| signInPage: | ||
| importName: CustomSignInPage | ||
| ---- | ||
|
|
||
| [NOTE] | ||
| ==== | ||
| The `package_name` specified under `dynamicPlugins.frontend` must match the `scalprum.name` value in the `package.json` file of your plugin to ensure the dynamic plugin loads correctly at runtime. | ||
| The `module` field is optional and allows specifying which set of assets must be accessed within the dynamic plugin. By default, the system uses the `PluginRoot` module. | ||
| ==== |
22 changes: 22 additions & 0 deletions
22
modules/dynamic-plugins/proc-adding-application-header.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| [id="proc-adding-application-header.adoc_{context}"] | ||
| = Adding application header | ||
|
|
||
| You can customize global headers by specifying configurations in the `app-config.yaml` file as shown in the following example: | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| # app-config.yaml | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| mountPoints: | ||
| - mountPoint: application/header # Adds the header as a global header | ||
| importName: <header_component> # Specifies the component exported by the global header plugin | ||
| config: | ||
| position: above-main-content # Supported values: (`above-main-content`| above-sidebar`) | ||
| ---- | ||
|
|
||
| [NOTE] | ||
| ==== | ||
| To configure multiple global headers at different positions, add entries to the `mountPoints` field. | ||
| ==== |
20 changes: 20 additions & 0 deletions
20
modules/dynamic-plugins/proc-adding-application-listeners.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| [id="proc-adding-application-listeners.adoc_{context}"] | ||
| = Adding application listeners | ||
|
|
||
| You can add application listeners using the `application/listener` mount point as shown in the following example: | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| # app-config.yaml | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| mountPoints: | ||
| - mountPoint: application/listener | ||
| importName: <exported listener component> | ||
| ---- | ||
|
|
||
| [NOTE] | ||
| ==== | ||
| You can configure multiple application listeners by adding entries to the `mountPoints` field. | ||
| ==== |
25 changes: 25 additions & 0 deletions
25
modules/dynamic-plugins/proc-adding-application-providers.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| [id="proc-adding-application-providers.adoc_{context}"] | ||
|
|
||
| = Adding application providers | ||
|
|
||
| You can add application providers using the `application/provider` mount point. You can use a mount point to configure a context provider as shown in the following example: | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| # app-config.yaml | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| dynamicRoutes: | ||
| - path: /<route> | ||
| importName: Component # The component to load on the route | ||
| mountPoints: | ||
| - mountPoint: application/provider | ||
| importName: <exported provider component> | ||
| ---- | ||
|
|
||
| [NOTE] | ||
| ==== | ||
| . You can configure multiple application providers by adding entries to the `mountPoints` field. | ||
| . The `package_name` key under `dynamicPlugins.frontend` **must match** the `scalprum.name` value in the `package.json` file of your plugin. This ensures your dynamic plugin loads correctly at runtime. | ||
| ==== |
25 changes: 25 additions & 0 deletions
25
modules/dynamic-plugins/proc-adding-custom-authentication-provider-settings.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| [id="proc-adding-custom-authentication-provider-settings.adoc_{context}"] | ||
| = Adding custom authentication provider settings | ||
|
|
||
| You can install new authentication providers from a dynamic plugin that either adds additional configuration support for an existing provider or adds a new authentication provider. These providers are listed in the user settings section under the *Authentication Providers* tab. | ||
|
|
||
| You can use the `providerSettings` configuration to add entries for an authentication provider from a dynamic plugin, as shown in the following example: | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| providerSettings: | ||
| # The title for the authentication provider shown above the user's profile image if available | ||
| - title: My Custom Auth Provider | ||
| # The description of the authentication provider | ||
| description: Sign in using My Custom Auth Provider | ||
| # The ID of the authentication provider as provided to the `createApiRef` API call. | ||
| provider: core.auth.my-custom-auth-provider | ||
| ---- | ||
|
|
||
| [NOTE] | ||
| ==== | ||
| `provider` looks up the corresponding API factory for the authentication provider to connect the provider's Sign In/Sign Out button. | ||
| ==== |
44 changes: 44 additions & 0 deletions
44
modules/dynamic-plugins/proc-binding-to-existing-plugins.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| [id="proc-binding-to-existing-plugins.adoc_{context}"] | ||
| = Binding to existing plugins | ||
|
|
||
| You can bind to existing plugins and their routes, and declare new targets sourced from dynamic plugins as shown in the following `routeBindings` configuration: | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| # dynamic-plugins-config.yaml | ||
| plugins: | ||
| - plugin: <plugin_path_or_url> | ||
| disabled: false | ||
| pluginConfig: | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| routeBindings: | ||
| targets: # A new bind target | ||
| # (Optional): Defaults to importName. Explicit name of the plugin that exposes the bind target. | ||
| - name: barPlugin | ||
| # (Required): Explicit import name that reference a BackstagePlugin<{}> implementation. | ||
| importName: barPlugin | ||
| # # (Optional): Same as key in `scalprum.exposedModules` key in the `package.json` file of the plugin. | ||
| module: CustomModule | ||
| bindings: | ||
| - bindTarget: "barPlugin.externalRoutes" # (Required): One of the supported or imported bind targets | ||
| bindMap: # A required map of route bindings similar to `bind` function options | ||
| headerLink: "fooPlugin.routes.root" | ||
| ---- | ||
|
|
||
| To configure `routeBindings`, complete the following steps: | ||
|
|
||
| . Define new targets using `routeBindings.targets`. Set the required `importName` to a `BackstagePlugin<{}>` implementation. | ||
|
|
||
| . Declare route bindings using the *routeBindings.bindings* field by setting `bindTarget` to the name of the target to bind to. This is a dynamic or static target, such as: | ||
jmagak marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| + | ||
| ** `catalogPlugin.externalRoutes` | ||
|
|
||
| ** `catalogImportPlugin.externalRoutes` | ||
|
|
||
| ** `techdocsPlugin.externalRoutes` | ||
|
|
||
| ** `scaffolderPlugin.externalRoutes` | ||
| + | ||
| You can extend existing pages with additional content using mount points, which are predefined identifiers available throughout the application. | ||
128 changes: 128 additions & 0 deletions
128
modules/dynamic-plugins/proc-customizing-and-extending-entity-tabs.adoc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,128 @@ | ||
| [id="proc-customizing-and-extending-entity-tabs.adoc_{context}"] | ||
|
|
||
| = Customizing and extending entity tabs | ||
|
|
||
| You can customize and extend the set of tabs using the `entityTabs` configuration as follows: | ||
|
|
||
| [source,yaml] | ||
| ---- | ||
| # dynamic-plugins-config.yaml | ||
| plugins: | ||
| - plugin: <plugin_path_or_url> | ||
| disabled: false | ||
| pluginConfig: | ||
| dynamicPlugins: | ||
| frontend: | ||
| my-plugin: # The plugin package name | ||
| entityTabs: | ||
| # Specify a new tab | ||
| - path: /new-path | ||
| title: My New Tab | ||
| mountPoint: entity.page.my-new-tab | ||
| # Change an existing tab's title or mount point | ||
| - path: / | ||
| title: General | ||
| mountPoint: entity.page.overview | ||
| # Specify the sub-path route in the catalog where this tab is available | ||
| - path: "/pr" | ||
| title: "Changed Pull/Merge Requests" # Specify the title you want to display | ||
| priority: 1 | ||
| # The base mount point name available on the tab. This name expands to create two mount points per tab, with` /context` and with `/cards` | ||
| mountPoint: "entity.page.pull-requests" | ||
| - path: "/" | ||
| title: "Changed Overview" | ||
| mountPoint: "entity.page.overview" | ||
| # Specify the order of tabs. The tabs with higher priority values appear first | ||
| priority: -6 | ||
| ---- | ||
|
|
||
| You can configure dynamic front-end plugins to target the mount points exposed by the entityTabs configuration. The following are the default catalog entity routes in the default order: | ||
|
|
||
| .Input parameters | ||
| [cols="20%,20%,30%,30%", frame="all", options="header"] | ||
| |=== | ||
| |Route | ||
| |Title | ||
| |Mount Point | ||
| |Entity Kind | ||
|
|
||
| |`/` | ||
| |Overview | ||
| |`entity.page.overview` | ||
| |Any | ||
|
|
||
| |`/topology` | ||
| |Topology | ||
| |`entity.page.topology` | ||
| |Any | ||
|
|
||
| |`/issues` | ||
| |Issues | ||
| |`entity.page.issues` | ||
| |Any | ||
|
|
||
| |`/pr` | ||
| |CPull/Merge Requests | ||
| |`entity.page.pull-requests` | ||
| |Any | ||
|
|
||
| |`/ci` | ||
| |CI | ||
| |`entity.page.ci`` | ||
| |VAny | ||
|
|
||
| |`/cd` | ||
| |CD | ||
| |`entity.page.cd` | ||
| |Any | ||
|
|
||
| |`/kubernetes` | ||
| |Kubernetes | ||
| |`entity.page.kubernetes` | ||
| |Any | ||
|
|
||
| |`/image-registry` | ||
| |Image Registry | ||
| |`entity.page.image-registry` | ||
| |Any | ||
|
|
||
| |`/monitoring` | ||
| |Monitoring | ||
| |`entity.page.monitoring` | ||
| |Any | ||
|
|
||
| |`/lighthouse` | ||
| |Lighthouse | ||
| |`entity.page.lighthouse` | ||
| |Any | ||
|
|
||
| |`/api` | ||
| |Api | ||
| |`entity.page.api` | ||
| |kind: Service or kind: Component | ||
|
|
||
| |`/dependencies` | ||
| |Dependencies | ||
| |`entity.page.dependencies` | ||
| |kind: Component | ||
|
|
||
| |`/docs` | ||
| |Docs | ||
| |`entity.page.docs` | ||
| |Any | ||
|
|
||
| |`/definition` | ||
| |Definition | ||
| |`entity.page.definition` | ||
| |kind: API | ||
|
|
||
| |`/system` | ||
| |Diagram | ||
| |`entity.page.diagram` | ||
| |kind: System | ||
| |=== | ||
|
|
||
| [NOTE] | ||
| ==== | ||
| Mount points within Catalog such as _`entity.page.*`_ are rendered as tabs and become visible only if at least one plugin contributes to them, or if they can render static content. | ||
| ==== |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.