-
Notifications
You must be signed in to change notification settings - Fork 811
Kinds #7468
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
base: main
Are you sure you want to change the base?
Kinds #7468
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,14 +1,10 @@ | ||
| --- | ||
| description: A kind extension provides the preset for other extensions to use. | ||
| description: Create reusable, standardized configurations for extensions, helping to streamline development, ensure consistency, and reduce duplication. | ||
| --- | ||
|
|
||
| # Kind | ||
|
|
||
| {% hint style="warning" %} | ||
| This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice. | ||
| {% endhint %} | ||
|
|
||
| A Kind is a preset configuration that can be inherited by extensions to ensure consistency and reduce redundancy. It defines a set of default properties or behaviors that extensions can adopt, making it easier to maintain and configure extensions that share similar functionality. | ||
| A Kind is a preset configuration that extensions can inherit to ensure consistency and reduce redundancy. It defines a set of default properties or behaviors that extensions can adopt, making it easier to maintain and configure extensions that share similar functionality. | ||
|
|
||
| A Kind is always linked to a specific extension type. Extensions using the same type and referencing a Kind automatically inherit its settings, ensuring uniformity across different extensions. | ||
|
|
||
|
|
@@ -33,7 +29,9 @@ To register a Kind, use the same method as other extensions. The key properties | |
| The following example shows how to register a Button Kind for [**Header Apps**](../extension-types/header-apps.md). This kind provides a preset configuration for a button element that can be reused by other Header App extensions. | ||
|
|
||
| ```typescript | ||
| const manifest: ManifestKind = { | ||
| import type { UmbExtensionManifestKind } from "@umbraco-cms/backoffice/extension-registry"; | ||
|
|
||
| export const customHeaderAppButton: UmbExtensionManifestKind = { | ||
| type: 'kind', | ||
| alias: 'Umb.Kind.MyButtonKind', // Unique alias for the Kind | ||
| matchType: 'headerApp', // Applies to Header App extensions | ||
|
|
@@ -45,7 +43,7 @@ const manifest: ManifestKind = { | |
| }; | ||
| ``` | ||
|
|
||
| In this example: | ||
| Properties: | ||
|
|
||
| - `type` is set to 'kind' to register it as a Kind extension. | ||
| - `matchType` is 'headerApp', specifying that this Kind is for Header App extensions. | ||
|
|
@@ -80,32 +78,41 @@ In this example, the Header App extension uses the `kind: 'button'`, meaning it | |
|
|
||
| Hereβs an example of how to register and use the Button Kind in a Header App extension: | ||
|
|
||
| {% code title="kinds/manifests.ts" %} | ||
|
|
||
| {% hint style="info" %} | ||
| This example uses the dynamic extension registration approach. `umbExtensionsRegistry.register()` might be called from within an entrypoint lifecycle method like `onInit()`. For more information, see the [Backoffice Entry Point](./backoffice-entry-point.md) article. | ||
| {% endhint %} | ||
|
|
||
| ```typescript | ||
| import { umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry'; | ||
| import type { UmbExtensionManifestKind } from "@umbraco-cms/backoffice/extension-registry"; | ||
|
|
||
| const manifest: UmbExtensionManifest = { | ||
| export const customHeaderAppButton: UmbExtensionManifestKind = { | ||
| type: 'kind', | ||
| alias: 'Umb.Kind.MyButtonKind', // Alias for the Kind | ||
| matchType: 'headerApp', // Extension type the Kind applies to | ||
| matchKind: 'button', // Defines the Kind alias | ||
| matchKind: 'customHeaderAppButton', // Defines the Kind alias | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Based on the text above, this example uses one of the Core Kinds for HeaderApps. In otherwords should stay 'button' But maybe we should change the text above and make this use the custom one from further up. In other words keep this and then correct line 81. |
||
| manifest: { | ||
| elementName: 'umb-header-app-button', | ||
| }, | ||
| }; | ||
|
|
||
| umbExtensionsRegistry.register(manifest); | ||
| ``` | ||
| {% endcode %} | ||
|
|
||
| This code registers the Button Kind, so other Header App extensions using `type: 'headerApp'` and `kind: 'button'` will inherit the preset `elementName: 'umb-header-app-button'`. | ||
| This code registers the Button Kind, so other Header App extensions using `type: 'headerApp'` and `kind: 'customHeaderAppButton'` will inherit the preset `elementName: 'umb-header-app-button'`. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again here, the |
||
|
|
||
| Now, another Header App extension can be created without defining `elementName`, as it will automatically inherit it from the Kind: | ||
| Now another Header App extension can be created without defining `elementName`, as it will automatically inherit it from the Kind: | ||
|
|
||
| {% code title="kinds/manifests.ts" %} | ||
| ```typescript | ||
| import { extensionRegistry } from '@umbraco-cms/extension-registry'; | ||
| import { umbExtensionsRegistry } from "@umbraco-cms/backoffice/extension-registry"; | ||
|
|
||
| const manifest = { | ||
| type: 'headerApp', // Extension type | ||
| kind: 'button', // References the 'button' Kind | ||
| kind: 'customHeaderAppButton', // References the matchKind property ('customHeaderAppButton') | ||
| name: 'My Header App Example', | ||
| alias: 'My.HeaderApp.Example', | ||
| meta: { | ||
|
|
@@ -115,9 +122,8 @@ const manifest = { | |
| }, | ||
| }; | ||
|
|
||
| extensionRegistry.register(manifest); | ||
| umbExtensionsRegistry.register(manifest); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, I think we should stop putting the registration code in the examples, just keep the manifest |
||
| ``` | ||
| {% endcode %} | ||
|
|
||
| By referencing the Kind, the extension inherits shared properties like `elementName`, ensuring consistency and reducing redundancy across extensions. This method also makes it easier to update configurations across multiple extensions. | ||
|
|
||
| By using Kinds, you can create reusable, standardized configurations for extensions, helping to streamline development, ensure consistency, and reduce duplication. Understanding how to register and reference Kinds effectively will enhance the maintainability of your Umbraco extensions. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its inconsistent to present this manifest registration approach when the one above did not have that. So we may just remove the
umbExtensionsRegistry.register(manifest);from the example and get rid of this part.And the point of getting to Kinds, I hope people would have gotten the part about manifest registration? But ofcourse I might be wrong... :-)