You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 16/umbraco-cms/customizing/extending-overview/extension-types/kind.md
+26-17Lines changed: 26 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,10 @@
1
1
---
2
-
description: A kind extension provides the preset for other extensionsto use.
2
+
description: Create reusable, standardized configurations for extensions, helping to streamline development, ensure consistency, and reduce duplication.
3
3
---
4
4
5
5
# Kind
6
6
7
-
{% hint style="warning" %}
8
-
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.
9
-
{% endhint %}
10
-
11
-
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.
7
+
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.
12
8
13
9
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.
14
10
@@ -33,7 +29,7 @@ To register a Kind, use the same method as other extensions. The key properties
33
29
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.
alias: 'Umb.Kind.MyButtonKind', // Unique alias for the Kind
39
35
matchType: 'headerApp', // Applies to Header App extensions
@@ -49,7 +45,7 @@ In this example:
49
45
50
46
-`type` is set to 'kind' to register it as a Kind extension.
51
47
-`matchType` is 'headerApp', specifying that this Kind is for Header App extensions.
52
-
-`matchKind` is 'button', which is the alias of the Kind.
48
+
-`matchKind` is 'button,' which is the alias of the Kind.
53
49
- The `manifest` contains default properties like elementName that extensions using this Kind will inherit.
54
50
55
51
## Using the Kind in Other Extensions
@@ -80,32 +76,46 @@ In this example, the Header App extension uses the `kind: 'button'`, meaning it
80
76
81
77
Here’s an example of how to register and use the Button Kind in a Header App extension:
82
78
79
+
{% code title="kinds/manifests.ts" %}
80
+
81
+
{% hint style="warning" %}
82
+
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.
alias: 'Umb.Kind.MyButtonKind', // Alias for the Kind
89
92
matchType: 'headerApp', // Extension type the Kind applies to
90
-
matchKind: 'button', // Defines the Kind alias
93
+
matchKind: 'customHeaderAppButton', // Defines the Kind alias
91
94
manifest: {
92
95
elementName: 'umb-header-app-button',
93
96
},
94
97
};
95
98
96
99
umbExtensionsRegistry.register(manifest);
97
100
```
101
+
{% endcode %}
98
102
99
-
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'`.
103
+
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'`.
100
104
101
-
Now, another Header App extension can be created without defining `elementName`, as it will automatically inherit it from the Kind:
105
+
Now another Header App extension can be created without defining `elementName`, as it will automatically inherit it from the Kind:
106
+
107
+
{% code title="kinds/manifests.ts" %}
108
+
109
+
{% hint style="warning" %}
110
+
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.
kind: 'customHeaderAppButton', // References the matchKind property ('customHeaderAppButton')
109
119
name: 'My Header App Example',
110
120
alias: 'My.HeaderApp.Example',
111
121
meta: {
@@ -115,9 +125,8 @@ const manifest = {
115
125
},
116
126
};
117
127
118
-
extensionRegistry.register(manifest);
128
+
umbExtensionsRegistry.register(manifest);
119
129
```
130
+
{% endcode %}
120
131
121
132
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.
122
-
123
-
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.
0 commit comments