Ein großer Vorteil von KoliBri liegt in seiner besonders guten Wiederverwendbarkeit und hohen Flexiblität. Denn auf Basis der semantisch barrierefreien Komponenten, in denen alle technische und gesetzliche Anforderungen umgesetzt sind, können eigene Themes unabhängig erstellt werden.

Rückblick​

KoliBri wurde als internes Projekt des ITZBund realisiert und hat sich natürlich dabei anfangs vor allem auf die Bedürfnisse interner Projekte fokussiert. Hierbei sind in erster Linie zahlreiche Themes umgesetzt worden, die nur intern Anwendung finden.

Darüber hinaus wurden auch einige Themes zum Zwecke der Verbesserung umgesetzt, die als Proof-of-Concepts (PoC) dienten.

Migration​

Wir beschreiben jetzt hier in der Migration einfach mal, wie wir das im ITZBund exemplarisch umgesetzt haben, weil dass sicher ein interessanter Aspekt für andere Behörden, Organisationen und Unternehmen ist, wie sie eigene Themes intern bereitstellen können.

Im Grunde haben wir ein neues Repository angelegt und ein Theme-Projekt erstellt (siehe nächsten Abschnitt), in dem wir alle internen Themes pflegen. Wir haben erstmal alle Themes in einem Repository, weil wir das für die Entwicklung aktuell einfacher finden. Es ist aber auch möglich, die Themes in unterschiedlichen Repositories jeweils einzeln zu pflegen.

Mittels des TypeScript-Compilers wird das Theme-Projekt in ein JavaScript-Projekt kompiliert und als NPM-Paket @itzbund/interne-kolibri-themes in unsere interne NPM-Registry versioniert gepublished.

Damit die entwickelnden Projekte jetzt das neue Theme-Paket installieren und verwenden können, muss zunächst die NPM-Konfiguration .npmrc im Projekt-Verzeichnis erweitert und die neue Abhängigkeit in die package.json hinzugefügt werden.

.npmrc (kann mit im Projekt-Verzeichnis liegen oder im Home-Verzeichnis des Benutzers)

@itzbund:registry=https://<URL-zur-internen-registry>

package.json (im Projekt-Verzeichnis)

{
 "dependencies": {
  "@itzbund/interne-kolibri-themes": "1.0.0"
 }
}

Eigenes Theme erstellen​

In diesem Abschnitt wollen wir einen kurzen Einblick geben, wie einfach es ist, ein eigenes Theme zu erstellen.

Rationale​

Einer der wichtigsten Punkte, die man verstehen muss, liegt darin, dass KoliBri sich auf kleinteilige häufig wiederverwendete Komponenten konzentriert (mehr hierzu im ). Das führt dazu, dass wir uns vorallem auf standardisierbare Komponenten fokussieren. Deutlicher wird dies, wenn wir uns vorstellen, eine redundante Umsetzung einer Basis-Komponente unter Beachtung der technischen und gesetzlichen Anforderungen zu entwickeln und am Ende feststellen - die verhält sich ja genauso, wie eine KoliBri- Komponente und ist nahezu gleich semantisch aufgebaut. Insbesondere die technisch semantischen Vorgaben des W3C für die assistive Unterstützung (Barrierefreiheit) fördern das Standardisierungspotenzial.

Wir können somit von einer hohen Überdeckung von Komponenten ausgehen, die allgemein jedes Design System oder Komponenten-Bibliothek beinhalten und sich in der KoliBri-Sammlung verwendbar wiederfinden. Durch das Kompositionsprinzip kann einfach die passende Teilmenge aus KoliBri ausgewählt und wiederverwendet werden. Alle nicht vereinbarten Komponenten können unabhängig von KoliBri und unternehmensspezifisch umgesetzt werden.

Hinweis: Es ist immer möglich eine Konstellation gegen die Wiederverwendung einer KoliBri-Komponenten aufzustellen, die auf die Abweichung von der Referenzimplementierung abzielt. Es ist nicht unsere Entscheidung ob die aufgezeigte Abweichung eine vollständige Eigenentwicklung wirtschaftlich und ökonomisch rechtfertigt. Wir bieten eine Lösung an, die von alle frei und geprüft genutzt werden kann.

Umsetzung​

Mit Hilfe der KoliBri-CLI (npm init kolibri my-theme) kann ein neues Theme-Projekt generiert werden. Das Theme-Projekt ist ein TypeScript-Projekt und beinhalten schon ein Dummy-Theme. Mit Hilfe des KoliBri-Designers kann dann ein Theme interaktiv auf den Basis-Komponenten erstellt, gespeichert, geladen und weiter gepflegt werden. Der vom Designer generierte Code wird einfach in das Theme-Projekt kopiert und kann dann mit dem TypeScript-Compiler kompiliert werden. Anschließend kann es mittels NPM eine interne oder in die öffentliche NPM-Registry gepublished werden.

Today we offer the variants of Button, ButtonLink, Link and LinkButton. In the future we will also offer the ButtonToggle (Toogle button). All semantic links only support _href and all buttons only _on as a semantic "click". Visually, there are buttons that look exactly like links and links that look exactly like buttons.

The following table provides an overview of the differences:

Motivation​

In addition to a high level of standard conformity, KoliBri also strives for very good reusability (Developer Experience DX). This is addressed by the uniformity of the HTML attributes and the economical use of additional properties.

Rationale: Given a link component intended for navigation, if we consider the two behaviors Navigate and Click without navigating would offer, then we would have a contradiction in behavior. Also when used in development we would need the properties _href and _on make it optional and we could no longer warn against misuse (static code checking).

Challenges​

This strict interpretation can cause problems when developing with other libraries and frameworks. Especially when they expect a click on a link.

React-Router​

The React router maps navigation via clicks. When used with the link component, there are different implementation options.

Wrapping:

<Link to="/">
 <KolLink _href="">Home</KolLink>
</Link>
<Link to="/test">
 <KolLink _href="">Test</KolLink>
</Link>

With a click:

<KolButtonLink
 _label="Home"
 _on={{
  onClick: () => navigate("/")
 }}
>
 Home
</KolButtonLink>
<KolButtonLink
 _label="Test"
 _on={{
  onClick: () => navigate("/test")
 }}
>
 Test
</KolButtonLink>

React-Link:

<KolLink
 _href=""
 _label="Home"
 onClick={() => navigate("/")}
>
 Home
</KolLink>
<KolLink
 _href=""
 _label="Test"
 onClick={() => navigate("/test")}
>
 Test
</KolLink>

Notice: _href="" is actually not allowed.

HThere is also a small code example here Navigate with React router.

The provided examples show that the Link and ButtonLink components are suitable for direct use with React-Router. However, the link component is also used within other KoliBri components. Where that wouldn't work!

Server side rendering​

The server-side rendering is very similar to the React router because it is technically very strongly driven by the Remix framework. Remix is ​​a framework for building hybrid client and server side web applications. This means that the implementation does not differ whether I want to build the application later as a client or server-side application. For server-side applications, the one-click navigating links must work because these applications run on the server and not in the browser.

In order to ensure that KoliBri can also be used for server-side web applications, it must also be possible to change pages by clicking without navigating.

Solution​

To solve the challenges, all components that are passed link definitions are expanded. If ButtonLink definitions can also be transferred to these components, then they can also display clicks without navigating, but they still look like links. The following components must also be expanded:

• Breadcrumb
• LinkGroup
• Nav
• SkipNav

As an open source project, it is important for KoliBri to have a community around to build up the topic of accessible basic components. So for this too optimal accessibility is given, all technical Specifications must be available in at least English. As in the Science allows for feedback and participation from all potential areas.

Todo​

English specification​

The technical specification is automatically generated from the source code and synchronized. All the information we put from the source code into the Transfer specification, will in future only be in English provided.

This concerns, for example:

• API specification on the website
• Details in IDE autocompletion
• Representations generated from the meta data of the source code

Multilinguale Dokumentation​

In the future (in the medium term), the documentation will primarily include all content in German and secondary in English provided.

This concerns, for example:

• Instructions, concepts, examples and much more.
• Blog posts