1 of 1

3.4 Implementation

Dieses Kapitel behandelt das Vorgehen während des Implementations-Prozesses. In der Prototyping-Phase entsteht der erste HTML Prototyp. Durch das Anwenden des Refactoring löst sich dieser chaotische Code auf. Im iterativen Prozess entstehen sechs aufgeräumte und dokumentierte Files.

3.4.1 Prototyping in HTML

Parallel zur Ausarbeitung der Details des Figma Prototypen entsteht ein Lo-Fi HTML-Prototyp (Appendix D). Ziel des Codes ist eine erste, rudimentäre Implementation zu erstellen. Damit zeigt sich ein erster Beweis für die Umsetzbarkeit der konzeptionell geplanten Komponente.

Code Snippet 3.4

<html>
    <head>
        <!-- head tags -->
        <style>
            /* all styles here */
        </style>
    </head>
    <body>
        <!-- html view -->
        <script src="countries.js"></script>
        <script defer>
            /* all js here */
        </script>
    </body>
</html>

Dieser Prototyp (Code Snippet 3.4) bestehend aus einer Datei enthält den gesamten HTML, CSS (Zeile 5) und JavaScript (Zeile 12) Code. Wegen der grossen Datenmenge (Zeile 10) resultiert die Entscheidung diesen Code als einzigen in eine externe Datei (Zeile 10, Appendix C) auszulagern. Dies vereinfacht die Verwendung in weiteren Prototypen. Ein Auszug aus der Datenmenge von Appendix C ist in Code Snippet 3.5 ersichtlich.

Code Snippet 3.5

const countryList = [
    {
        country: "Afghanistan",
        code: "AF",
        code2: "AFG",
        domain: "af",
        continent: "Asia",
    },
    {
        country: "Albania",
        code: "AL",
        code2: "ALB",
        domain: "al",
        continent: "Europe",
    },
    {
        country: "Algeria",
        code: "DZ",
        code2: "DZA",
        domain: "dz",
        continent: "Africa",
    },
    ...
];

Wenn sich das Konzept im Lo-Fi Prototyp als gut erweist, entwickelt sich der Ansatz zu einem Hi-Fi Prototyp (Appendix E) weiter. Dabei kommt der erste tiefere Kontakt mit der Codebasis zustande.

Code Snippet 3.6

@import url("../../docs/css/kolibri-base.css");
@import url("../../docs/css/kolibri-light-colors.css");
@import url("../../docs/css/kolibri-light-fonts.css");

:root {
    --color-selected: var(--kolibri-color-select, hsl(46, 90%, 84%));
    --color-selected-secondary: var(--kolibri-color-shadow, hsl(46, 80%, 92%));
    --color-focused: hsl(322, 73%, 52%);
    /* more style variables here */
}
/* more styles here */

Als wichtige CSS Dateien erweisen sich kolibri-base.css, kolibri-light-colors.css und kolibri-light-fonts.css des Kolibri-Repository (Appendix B) . Diese finden sich in den Importen im <style>-Tag wieder (Code Snippet 3.6).

Bei den JS-Dateien stechen die Dateien aus dem Ordner simpleForm heraus. Die drei Files des SimpleInput zeigen den Aufbau einer vorhandenen Formularkomponente. Diese Struktur dient beim späteren Refactoring (Kapitel 3.4.2) als Vorlage bzw. Beispiel.

Der Hi-Fi Prototyp von Kapitel 3.2.3 beinhaltet eine Bedienung mit der Tastatur (Code Snippet 3.7) und bietet eine Möglichkeit zur Suche.

Code Snippet 3.7

const inputElement = /* create element */;
inputElement.onkeydown = (e) => {
    switch (e.code ?? e.key ?? e.keyCode) {
        case "ArrowLeft": /* handle action */
        /* more navigation actions */
        case "Enter": /* handle action */
        /* more actions */
        default: /* nothing happens */
    }
};

Die Navigation (Code Snippet 3.7) mit den Pfeiltasten, sowie weiteren typischen Aktionstasten ist über ein Key Event geregelt. Diese Umsetzung kümmert sich nur im die grundlegenden Tasten, welche von den meisten anderen Elementen ebenfalls unterstützt werden.

3.4.2 Refactoring inkl. Entwicklung

In der weiteren Entwicklung des HTML Hi-Fi Prototypen aus dem Appendix E kommt das Refactoring in iterativen Schritten zum Zuge. Bei der ersten Überarbeitung liegt der Fokus auf dem Aufteilen des gesamten Codes in mehrere Dateien. Die Zerlegung schafft eine bessere Struktur. Es entsteht pro Technologie ein File. In der weiteren Entwicklung geschieht das unabhängige, repetitive Refactoring der drei Dateien.

Das CSS teilt sich in zwei Dateien (CSS-Dateien im Appendix F). Eine Datei dient der Verwaltung der Variablen, welche für die Komponente zuständig sind. Das Design der einzelnen Selektoren steht im zweiten File. Da dieser Teil noch sehr viel Code enthält, hilft eine weitere Iteration der Überarbeitung. Diese prüft die einzelnen Properties auf ihre Notwendigkeit und erstellt eine Ordnung bzw. Gruppierung der Selektoren. In Kombination zum Refactoring wird das Design optimiert und entdeckte Fehler korrigiert.

Code Snippet 3.8

<!-- link to js code -->
<script src="./dropdown.js" type="module"></script>

Code Snippet 3.9

import { countryList } from "./countries.js";

/* JS code */

Auf der anderen Seite vereinfacht die Modularisierung (Code Snippet 3.8 & 3.9) des erstellten JS-Files die weitere Überarbeitung des Codes. Der zweite Refactoring-Durchlauf löst die Komplexität aus dem Prototypen ein wenig auf. Dies geschieht indem die Variablen eine saubere Benennung erhalten. Zudem entstehen Funktionen mit einem klaren Ziel, welche an den ursprünglichen Stellen aufgerufen werden. Im gleichen Schritt entwickelt sich der erste Prototyp der Suche. Während dieses Durchgangs entsteht parallel der erste Teil des JSDoc. Die Umsetzung des Projector Pattern als auch der Debounce Suche folgt im Zusammenhang mit weiteren Iterationen des Refactoring.

3.4.2.1 Projector Pattern

Das Projector Pattern teilt den komplexen JS-Code in drei modulare Komponenten (JS-Dateien im Appendix F). Um das UI testbar zu implementieren, gesellt sich zu diesen Files noch ein weiteres mit dem JS-Starter Code dazu. Die klare Trennung der Verantwortlichkeiten unterstützt die Wartung als auch die Weiterentwicklung des Codes. Die Wiederverwendbarkeit wird dadurch gesteigert. Da diese Struktur bereits beim SimpleInput umgesetzt ist, dient diese Komponente als gute Vorlage. Die Abhängigkeiten zwischen den einzelnen Dateien minimiert sich. Bei der Umsetzung des Patterns reduziert sich der Code im HTML-File auf wenige Zeilen (Code Snippet 3.10).

Code Snippet 3.10

<!-- main container for dropdown -->
<div class="countrySelectionView dropdown" id="container">
    <!-- dynamic generated by JavaScript code -->
</div>

Die Analyse des SimpleInput offenbart, dass bereits ein Debounce-Input existiert. In der folgenden Passage ist beschrieben, wie diese zum Einsatz kommt.

3.4.2.2 Debounced Searching

Im Refactoring- und Optimierungsprozess der Suche bietet sich eine Debounce-Funktion an. Diese kommt ohne ein sichtbares UI-Feld aus. Der default case des Key Events (Code Snippet 3.7) für die Auswahlkomponente definiert die Aktion von Tasteneingaben einzelner Symbole wie z.B. Buchstaben. Das Debounce fügt alle Eingaben innerhalb einer Zeitspanne zu einem Suchbegriff zusammen. Dieser wiederum kommt bei der Suche zum Zuge. Die vorhandene Debounce-Komponente bietet sich an, um den Suchbegriff zu verwalten (Appendix F, Datei choiceInputProjector.js). Zusätzlich löst die Eingabe einen Trigger für die Suche in der Länder-Liste aus. Das dafür notwendige Input-Feld dient rein zur Verwaltung der Daten und zum Triggern der Suche. Das UI hat keine Kenntnisse von diesem Input und ist dadurch vor Manipulationen geschützt.

Bei einer weiteren Analysierung der soweit entstandenen Komponente zeigt sich ein Master-Detail Aufbau. Dieses Muster lässt sich in einer nächsten Iteration des Refactoring umsetzen.

3.4.2.3 Master-Detail View

Jede dieser JS-Dateien erhält bei der Umsetzung des Master-Detail Pattern Änderungen. Eine sinnvolle Reihenfolge für die Überarbeitungen der Pattern-Komponenten startet beim Model (Code Snippet 3.11), gefolgt vom Controller (Code Snippet 3.12) und zum Schluss der Projector (Code Snippet 3.13).

Code Snippet 3.11

export { ChoiceDetailModel, ChoiceMasterModel };

const ChoiceDetailModel = ({value, placeholder, label, name}) => {
    /* detail model logic */
};
const ChoiceMasterModel = ({elementList, sectionElement, focusObject}) => {
    /* master model logic */
};

Code Snippet 3.12

import { ChoiceDetailModel, ChoiceMasterModel } from "./choiceInputModel.js";

export { ChoiceDetailController, ChoiceMasterController };

const ChoiceDetailController = (args) => /* detail controller logic */
const ChoiceMasterController = (categoryColumn, elementColumn, timeout = 800) =>
                                (args) => /* master controller logic */

Code Snippet 3.13

const projectChoiceInput = (detailController, masterController, formCssClassName) => {
    /* projector logic */
};

Die ersten zwei Files trennen ihren Inhalt in einen Master und einen Detail (Code Snippet 3.11 & 3.12) Teil auf. Dadurch entstehen jeweils zwei getrennte Models und zwei unabhängige Controller. Der Projector (Code Snippet 3.13) erwartet durch angepasste Parameter nun je einen Master- und einen Detail-Controller. Im Starter Code ist es nun notwendig die Models als auch die Controller separat zu erstellen und gemeinsam dem Projector zu übergeben.

Der Detail View erhält die Daten der Kopfzeile der Komponente. Die Informationen sind sowohl im geschlossenen als auch im offenen Zustand sichtbar. Die Master Ansicht ist nur in letzterem Status im UI sichtbar. Zugleich verwaltet es den Zustand als auch den Debounce-Text der Komponente. Folgende detaillierte Aufteilung entwickelt sich während des Refactoring und der Umsetzung des Patterns.

Detail:

Selektiertes Element aus Werte-Liste (Value)
Platzhalter
Label
Name (für Formulare)

Master:

Liste aller Elemente
Selektionsobjekt aus Kategorie und Value
Fokusobjekt aus aktiver Spalte und Element (Kategorie oder Value)

3.4.3 Fazit

Das Prototyping im HTML zeigt schnelle Erfolge, ohne sich sehr lange mit den Details aufzuhalten. Der schrittweise Ausbau unterstützt die Entwicklung. Mit dessen wiederholten Beschäftigung wird der Code immer klarer. Anfangs komplex erscheinende Stellen der Codebasis oder eigener Dateien, erscheinen verständlicher. Die erhaltene Klarheit des Codes hilft bei der Dokumentation. Das Refactoring unterstützt die Entwicklung insofern, dass sich Fehler durch das Umschreiben offenbaren. Hierbei grenzen sich die Stellen ein und die Bugs lassen sich schneller beheben.