RHIDP-5152: Add Frontend Plugn Wiring Section

assemblies/dynamic-plugins/assembly-front-end-plugin-wiring.adoc

@@ -0,0 +1,55 @@
+[id="assembly-front-end-plugin-wiring_{context}"]
+= Front-end plugin wiring
+:context: assembly-front-end-plugin-wiring
+
+You can configure front-end plugins to do the following:
+
+* Extend the internal library of available icons
+* Declare a new full page by defining a new route
+* Extend to an existing page using router bindings
+* Use mount points within the application
+* Provide additional utility APIs or replace existing ones
+
+// 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.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]

modules/dynamic-plugins/con-providing-custom-scaffolder-field-extensions.adoc

@@ -0,0 +1,29 @@
+[id="con-providing-custom-scaffolder-field-extensions"]
+
+= 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.
+* Multiple field extensions can be registered by listing each in the configuration.
+
+[source,yaml]
+----
+dynamicPlugins:
+  frontend:
+    my-plugin: # <1>
+      scaffolderFieldExtensions:
+        - importName: MyNewFieldExtension # <2>
+----
+<1> Specify the plugin package name.
+<2> The `importName` 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 your plugin's `package.json`.
+====

modules/dynamic-plugins/con-using-custom-signinpage-component.adoc

@@ -0,0 +1,27 @@
+[id="con-using-custom-signinpage-component"]
+= Using a custom SignInPage component
+
+In {product} ({product-very-short}), the `SignInPage` component manages the application's authentication flow. The `SignInPage` 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` can be specified for the application at a time.
+
+[source,yaml]
+----
+dynamicPlugins:
+  frontend:
+    my-plugin: # <1>
+      signInPage:
+        importName: CustomSignInPage
+----
+<1> Specify the plugin package name.
+
+[NOTE]
+====
+The `package_name` under `dynamicPlugins.frontend` must match the `scalprum.name` value in your plugin's `package.json` to ensure the dynamic plugin loads correctly during runtime.
+
+The `module` field is optional and allows specifying which set of assets should be accessed within the dynamic plugin. By default, the system uses the `PluginRoot` module.
+====

modules/dynamic-plugins/proc-adding-application-header.adoc

@@ -0,0 +1,29 @@
+[id="proc-adding-application-header.adoc-catalog"]
+
+= 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:  # <1>
+      mountPoints:
+        - mountPoint: application/header # <2>
+          importName: <header_component> # <3>
+          config:
+            position: above-main-content # <4>
+----
+<1> Specify the plugin package name.
+<2> Specify where to add the header. To specify it as a global header, use `application/header`.
+<3> Specify the component exported by the global header plugin (for example, `GlobalHeader` for `red-hat-developer-hub.backstage-plugin-global-header).
+<4> Specify the header's position. The supported values include:
+* `above-main-content`: Positions the header above the main content area.
+* `above-sidebar`: Positions the header above the sidebar.
++
+[NOTE]
+====
+To configure multiple global headers at different positions, add entries to the `mountPoints` field.
+====

modules/dynamic-plugins/proc-adding-application-listeners.adoc

@@ -0,0 +1,22 @@
+[id="proc-adding-application-listeners"]
+
+= 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: # <1>
+      mountPoints:
+        - mountPoint: application/listener
+          importName: <exported listener component>
+----
+<1> Specify the plugin package name.
+
+[NOTE]
+====
+You can configure multiple application listeners by adding entries to the `mountPoints` field.
+====

modules/dynamic-plugins/proc-adding-application-providers.adoc

@@ -0,0 +1,27 @@
+[id="proc-adding-application-providers"]
+
+= 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: # <1>
+      dynamicRoutes:
+        - path: /<route>
+          importName: Component # <2>
+      mountPoints:
+        - mountPoint: application/provider
+          importName: <exported provider component>
+----
+<1> Specify the plugin package name.
+<2> Specify the component you want to load on the route.
+
+[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 your plugin's `package.json`. This ensures your dynamic plugin loads correctly during runtime.
+====

modules/dynamic-plugins/proc-adding-custom-authentication-provider-settings.adoc

@@ -0,0 +1,22 @@
+[id="proc-adding-custom-authentication-provider-settings"]
+
+= 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: # <1>
+      providerSettings:
+        - title: My Custom Auth Provider # <2>
+          description: Sign in using My Custom Auth Provider # <3>
+          provider: core.auth.my-custom-auth-provider # <4>
+----
+<1> Specify the plugin package name.
+<2> Specify the title for the authentication provider shown above the user's profile image if available.
+<3> Specify the description of the authentication provider.
+<4> Specify the ID of the authentication provider as provided to the `createApiRef` API call. This value is used to look up the corresponding API factory for the authentication provider to connect the provider's Sign In/Sign Out button.

modules/dynamic-plugins/proc-binding-to-existing-plugins.adoc

@@ -0,0 +1,49 @@
+[id="proc-binding-to-existing-plugins"]
+
+= 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: # <1>
+            routeBindings:
+              targets: # <2>
+                - name: barPlugin # <3>
+                  importName: barPlugin # <4>
+                  module: CustomModule # <5>
+              bindings:
+                - bindTarget: "barPlugin.externalRoutes" # <6>
+                  bindMap: # <7>
+                    headerLink: "fooPlugin.routes.root"
+----
+<1> Specify the plugin package name.
+<2> Declare a new bind target
+<3> (Optional): defaults to importName. Explicit name of the plugin that exposes the bind target.
+<4> Required. Explicit import name that reference a BackstagePlugin<{}> implementation.
+<5> (Optional): Same as key in `scalprum.exposedModules` key in plugin's `package.json`
+<6> (Required): One of the supported or imported bind targets
+<7> A required map of route bindings and is similar to `bind` function options
+
+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 can be a dynamic or static target, such as:
++
+** `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.