mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
54 lines
3.4 KiB
Plaintext
54 lines
3.4 KiB
Plaintext
:_mod-docs-content-type: ASSEMBLY
|
|
[id="overview-of-dynamic-plugins_{context}"]
|
|
= Overview of dynamic plugins
|
|
include::_attributes/common-attributes.adoc[]
|
|
:context: overview-of-dynamic-plugins
|
|
|
|
toc::[]
|
|
|
|
[id="dynamic-plug-in-overview"]
|
|
== About dynamic plugins
|
|
|
|
Dynamic plugins are deployed as workloads on the cluster. They allow you to add custom pages and other extensions to your console user interface at runtime. The `ConsolePlugin` custom resource registers plugins with the console, and a cluster administrator enables plugins in the `console-operator` configuration.
|
|
|
|
[id="dynamic-plugins-features"]
|
|
== Key features
|
|
|
|
A dynamic plugin allows you to make the following customizations to the {product-title} experience:
|
|
|
|
* Add custom pages.
|
|
* Add perspectives beyond administrator and developer.
|
|
* Add navigation items.
|
|
* Add tabs and actions to resource pages.
|
|
|
|
[id="general-plug-in-guidelines"]
|
|
== General guidelines
|
|
When creating your plugin, follow these general guidelines:
|
|
|
|
* link:https://nodejs.org/en/[`Node.js`] and link:https://yarnpkg.com/[`yarn`] are required to build and run your plugin.
|
|
* Prefix your CSS class names with your plugin name to avoid collisions. For example, `my-plugin_\_heading` and `my-plugin_\_icon`.
|
|
* Maintain a consistent look, feel, and behavior with other console pages.
|
|
* Follow link:https://www.i18next.com/[react-i18next] localization guidelines when creating your plugin. You can use the `useTranslation` hook like the one in the following example:
|
|
+
|
|
[source,ymal]
|
|
----
|
|
conster Header: React.FC = () => {
|
|
const { t } = useTranslation('plugin__console-demo-plugin');
|
|
return <h1>{t('Hello, World!')}</h1>;
|
|
};
|
|
----
|
|
|
|
* Avoid selectors that could affect markup outside of your plugins components, such as element selectors. These are not APIs and are subject to change. Using them might break your plugin. Avoid selectors like element selectors that could affect markup outside of your plugins components.
|
|
* Provide valid JavaScript Multipurpose Internet Mail Extension (MIME) type using the `Content-Type` response header for all assets served by your plugin web server. Each plugin deployment should include a web server that hosts the generated assets of the given plugin.
|
|
|
|
[discrete]
|
|
== PatternFly guidelines
|
|
When creating your plugin, follow these guidelines for using PatternFly:
|
|
|
|
* Use link:https://www.patternfly.org/components/all-components/[PatternFly] components and PatternFly CSS variables. Core PatternFly components are available through the SDK. Using PatternFly components and variables help your plugin look consistent in future console versions.
|
|
** Use Patternfly 4.x if you are using {product-title} versions 4.14 and earlier.
|
|
** Use Patternfly 5.x if you are using {product-title} 4.15 or later.
|
|
* Make your plugin accessible by following link:https://www.patternfly.org/accessibility/accessibility-fundamentals/[PatternFly's accessibility fundamentals].
|
|
* Avoid using other CSS libraries such as Bootstrap or Tailwind. They can conflict with PatternFly and will not match the console look and feel. Plugins should only include styles that are specific to their user interfaces to be evaluated on top of base PatternFly styles. Avoid importing styles such as `@patternfly/react-styles/**/*.css` or any styles from `@patternfly/patternfly` package in your plugin.
|
|
* The console application is responsible for loading base styles for all supported PatternFly version(s).
|