Skip to content

Commit a9e7fb4

Browse files
committed
chore: add faq and property concept
1 parent 75bb7ba commit a9e7fb4

File tree

4 files changed

+180
-2
lines changed

4 files changed

+180
-2
lines changed

dev/docs/03-faq.mdx

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -45,7 +45,15 @@ import { KolLink } from '@public-ui/react';
4545
Das Stylen von KoliBri-Komponenten erfolgt nicht allein eingebundenes CSS oder die Verwendung von CSS-Frameworks (wie z.B. Bootstrap, Material-UI, Tailwind CSS, etc.), sondern
4646
über das technische Setzen von CSS an der Komponente. Das hat den Vorteil, dass die Komponenten vom äußeren CSS unabhängig sind. Die Robustheit ist ein architektonischen Qualitätsziel. Sie spiegelt sich darin wieder, das nur die Komponente selbst über ihr Styling entscheidet.
4747
- **Wozu braucht man das Schema?**<br/>
48-
KoliBri basiert auf einer ausgeklügelten <KolLink _href="/docs/konzepte/architektur#einfach" _label="Architektur" />. Beispielsweise dient das kleine Schema-Paket (@public-ui/schema) dazu, die Tag-Namen und Sprach-Keys der KoliBri-Komponenten unabhängig von der konkreten Implementierung zu definieren. Dies ermöglicht bei der Theme-Erstellung ein komplett losgelöstes Arbeiten mit Autovervollständigung, ohne aber die Komponenten und deren Abhängigkeiten zu benötigen. Das hat Vorteile bei manchen Integrationsszenarien, wie z.B. bei statischen Seiten oder Content-Management-Systemen (CMS).
48+
KoliBri basiert auf einer ausgeklügelten <KolLink _href="/docs/concepts/architecture" _label="Architektur" />. Beispielsweise dient das kleine Schema-Paket (@public-ui/schema) dazu, die Tag-Namen und Sprach-Keys der KoliBri-Komponenten unabhängig von der konkreten Implementierung zu definieren. Dies ermöglicht bei der Theme-Erstellung ein komplett losgelöstes Arbeiten mit Autovervollständigung, ohne aber die Komponenten und deren Abhängigkeiten zu benötigen. Das hat Vorteile bei manchen Integrationsszenarien, wie z.B. bei statischen Seiten oder Content-Management-Systemen (CMS).
49+
50+
## Technisches
51+
52+
- **Wieso können KoliBri-Komponenten wirklich barrierefrei sein?**<br/>
53+
Die KoliBri-Komponenten sind softwarearchitektonisch so designed, dass sie sich nur über Properties instrumentieren lassen und nicht über eignenes reingebbares HTML. Das bedeutet, dass die Komponenten nur über die API (Properties) gesteuert werden können. Das ist ein Qualitätsmerkmal, da die Komponenten so nicht von außen manipuliert werden können. Die Komponenten sind sehr restriktiv und können somit in sich immer barrierefrei sein.<br/>
54+
Um aus dieser Restriktivität ausbrechen zu können, gibt es den <KolLink _href="/docs/concepts/expert-slot" _label="Expert-Slot" />, der es ermöglicht, eigenes HTML in die Komponente einzubetten. Die Barrierefreiheit über den Expert-Slot liegt in den Händen des Experten (Developers) und sollte nur in Ausnahmefällen verwendet werden.
55+
- **Warum werden die Eigenschaften von Komponenten manchmal abweichend vom HTML-Naming benannt?**<br/>
56+
Um die Erlernbarkeit von KoliBri zu einfach zu halten, wird in der Regel immer das Naming des HTML verwenden. Doch auch der HTML-Standard ist in seinem Naming über mehrerer Element (Komponenten) nicht einheitlich. Und daher kommt es dazu, dass wir in KoliBri für gleichartige Eigenschaften übergreifend einheitliche Namen gewählt haben. Mehr dazu finden Sie im Konzept <KolLink _href="/docs/concepts/properties" _label="Eigenschaften" />.
4957

5058
## Noch Fragen offen?
5159

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
---
2+
title: Eigenschaften
3+
description: Die Eigenschaften der Komponente werden auf dieser Seite beschrieben.
4+
tags:
5+
- Eigenschaften
6+
- Properties
7+
- Attribute
8+
- Konzept
9+
---
10+
11+
import { Properties } from '@site/src/components/Properties';
12+
13+
<Properties />

dev/i18n/en/docusaurus-plugin-content-docs/current/03-faq.mdx

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -45,7 +45,15 @@ import { KolLink } from '@public-ui/react';
4545
KoliBri components are not styled solely using embedded CSS or the use of CSS frameworks (such as Bootstrap, Material-UI, Tailwind CSS, etc.), but
4646
about the technical setting of CSS on the component. This has the advantage that the components are independent of the external CSS. Robustness is an architectural quality objective. It is reflected in the fact that only the component itself decides on its styling.
4747
- **Why do you need the scheme?**<br/>
48-
KoliBri is based on a sophisticated <KolLink _href="/docs/concepts/architecture#simple" _label="Architecture" />. For example, the small schema package (@public-ui/schema) is used to define the tag names and language keys of the KoliBri components independently of the concrete implementation. This enables completely detached work with auto-completion when creating the theme, but without needing the components and their dependencies. This has advantages in some integration scenarios, such as static pages or content management systems (CMS).
48+
KoliBri is based on a sophisticated <KolLink _href="/docs/concepts/architecture" _label="Architecture" />. For example, the small schema package (@public-ui/schema) is used to define the tag names and language keys of the KoliBri components independently of the concrete implementation. This enables completely detached work with auto-completion when creating the theme, but without needing the components and their dependencies. This has advantages in some integration scenarios, such as static pages or content management systems (CMS).
49+
50+
## Technical
51+
52+
- **Why can KoliBri components really be barrier-free?**<br/>
53+
The KoliBri components are designed in terms of software architecture in such a way that they can only be instrumented via properties and not via their own HTML that can be entered. This means that the components can only be controlled via the API (properties). This is a quality feature because the components cannot be manipulated from the outside. The components are very restrictive and can therefore always be barrier-free.<br/>
54+
In order to be able to break out of this restriction, there is the <KolLink _href="/docs/concepts/expert-slot" _label="Expert-Slot" />, which makes it possible to embed your own HTML in the component. Accessibility via the expert slot is in the hands of the expert (developer) and should only be used in exceptional cases.
55+
- **Why are component properties sometimes named differently from HTML naming?**<br/>
56+
In order to keep KoliBri easy to learn, the HTML naming is usually used. But even the HTML standard is not uniform in its naming across several elements (components). And that is why we have chosen uniform names for similar properties in KoliBri. See concept <KolLink _href="/docs/concepts/properties" _label="Properties" /> for more information.
4957

5058
## Any questions?
5159

dev/src/components/Properties.tsx

Lines changed: 149 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,149 @@
1+
import React, { FC } from 'react';
2+
3+
import ELEMENTS from '@public-ui/components/custom-elements.json';
4+
5+
const BLACKLIST = [
6+
'kol-button-group',
7+
'kol-color',
8+
'kol-counter',
9+
'kol-heading-wc',
10+
'kol-icon-font-awesome',
11+
'kol-icon-icofont',
12+
'kol-input-adapter-leanup',
13+
'kol-input-radio-group',
14+
'kol-kolibri',
15+
'kol-logo',
16+
'kol-link-group',
17+
'kol-span',
18+
'kol-span-wc',
19+
'kol-version',
20+
];
21+
type Property = 'components' | 'descriptions' | 'types';
22+
const COMPONENTS = new Map();
23+
const PROPS = new Map<string, Map<Property, Set<string>>>();
24+
ELEMENTS.tags.forEach((tag) => {
25+
if (BLACKLIST.indexOf(tag.name) === -1) {
26+
const componentName = tag.name.replace('kol-', '');
27+
if (COMPONENTS.has(componentName) === false) {
28+
COMPONENTS.set(componentName, {
29+
desc: tag.description,
30+
props: new Set(),
31+
});
32+
}
33+
tag.attributes.forEach((attribute) => {
34+
if (PROPS.has(attribute.name) === false) {
35+
const MAP = new Map<Property, Set<string>>();
36+
MAP.set('components', new Set());
37+
MAP.set('descriptions', new Set());
38+
MAP.set('types', new Set());
39+
PROPS.set(attribute.name, MAP);
40+
}
41+
const prop = PROPS.get(attribute.name);
42+
if (prop) {
43+
prop.get('components').add(componentName);
44+
prop.get('descriptions').add(attribute.description);
45+
prop.get('types').add(attribute.type.replace(/ \| undefined/g, ''));
46+
}
47+
});
48+
}
49+
});
50+
51+
const hideButton = new Map<Property, Set<string>>();
52+
hideButton.set('components', new Set(['kol-pagination']));
53+
hideButton.set('descriptions', new Set(['Versteckt entweder den Zurück- oder Weiter-Schalter, oder beide Schalter.']));
54+
hideButton.set('types', new Set(['"previous" | "next" | "both"']));
55+
PROPS.set('_hide-button', hideButton);
56+
57+
const DEPRECATED = new Map<string, Set<string>>();
58+
DEPRECATED.set('_align', new Set(['_alignment']));
59+
DEPRECATED.set('_hide-button', new Set(['_has-buttons']));
60+
DEPRECATED.set('_hide-label', new Set(['_icon-only']));
61+
DEPRECATED.set('_label', new Set(['_aria-label', '_caption', '_heading', '_headline', '_quote', '_summary', '_symbol', '_title']));
62+
// DEPRECATED.set('_list', new Set(['_links']));
63+
DEPRECATED.set('_variant', new Set(['_type<sup>*</sup>']));
64+
DEPRECATED.set('', new Set(['_has-buttons', '_has-footer', '_height', '_icon-align', '_part', '_show-dropdown']));
65+
66+
export const Properties: FC = () => {
67+
return (
68+
<div>
69+
<p>
70+
Ziel ist, möglichst über alle Komponenten einheitliche Eigenschaften (Properties) zu verwenden, um die Erlernbarkeit zu erleichtern. Folgende
71+
Anforderungen sind dafür definiert:
72+
</p>
73+
<ul>
74+
<li>Nur ein Property-Name für gleichartige Eigenschaften</li>
75+
<li>Wenn möglich, einheitliche Beschreibungen bei gleichen Propterty-Namen</li>
76+
<li>Wenn möglich, einheitliche Typen bei gleichen Propterty-Namen</li>
77+
<li>Anzahl an unterschiedlichen Properties, Beschreibungen und Typen minimieren</li>
78+
</ul>
79+
<h2>Aktueller Stand</h2>
80+
<table>
81+
<thead>
82+
<tr>
83+
<th>#</th>
84+
<th>Property</th>
85+
<th>Components</th>
86+
<th>Descriptions</th>
87+
<th>Types</th>
88+
</tr>
89+
</thead>
90+
<tbody>
91+
{Array.from(PROPS.keys()).map((prop, index) => {
92+
const components = Array.from(PROPS.get(prop)?.get('components') || []);
93+
const descriptions = Array.from(PROPS.get(prop)?.get('descriptions') || []);
94+
const types = Array.from(PROPS.get(prop)?.get('types') || []);
95+
return (
96+
<tr key={prop}>
97+
<td>{index}</td>
98+
<td>{prop}</td>
99+
<td>{components.join(', ')}</td>
100+
<td
101+
style={{ backgroundColor: descriptions.length > 1 && '#fbc' }}
102+
dangerouslySetInnerHTML={{
103+
__html: descriptions.join('<hr/>'),
104+
}}
105+
/>
106+
<td
107+
style={{ backgroundColor: types.length > 1 && '#fbc' }}
108+
dangerouslySetInnerHTML={{
109+
__html: types.join('"<hr/>"'),
110+
}}
111+
/>
112+
</tr>
113+
);
114+
})}
115+
</tbody>
116+
</table>
117+
<h2>Deprecated</h2>
118+
<p>Die in der folgenden Tabelle aufgelisteten Eigenschaften lösen zahlreiche veraltete Eigenschaften (-{Math.round((16 / PROPS.size) * 100)}%) ab.</p>
119+
<table>
120+
<thead>
121+
<tr>
122+
<th>New Property</th>
123+
<th>Deprecates Properties</th>
124+
</tr>
125+
</thead>
126+
<tbody>
127+
{Array.from(DEPRECATED.keys()).map((prop) => {
128+
const deprecated = Array.from(DEPRECATED.get(prop) || []);
129+
return (
130+
<tr key={prop}>
131+
<td>{prop}</td>
132+
<td
133+
dangerouslySetInnerHTML={{
134+
__html: deprecated.join(', '),
135+
}}
136+
></td>
137+
</tr>
138+
);
139+
})}
140+
</tbody>
141+
</table>
142+
<p>
143+
<small>
144+
<sup>*</sup> Betrifft nur Typen, die eigentlich Varianten meinen.
145+
</small>
146+
</p>
147+
</div>
148+
);
149+
};

0 commit comments

Comments
 (0)