
Es gab vor kurzem einen PR in unserem Mono-Repo, bei dem es hauptsächlich um die Einführung eines zentralen Services ging. Er sollte ab einem bestimmten Zeitpunkt von allen Apps des Repos konsumiert werden. Das einzige Manko des Services war:
Sein API arbeitete mit [Promises](https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Promise), sodass der Aufrufende gezwungen war, in seinen Komponenten oder eigenen Services, nicht wie gewohnt, mit [Rxjs-Observables](https://rxjs.dev/api/index/class/Observable) zu arbeiten, sondern mit Promises – so die Ausgangslage.

Hier eine stark abstrahierte Beispielimplementierung des Services:

```typescript
@Injectable({
  provideIn: 'root',
})
export class FooService {
  constructor(
    private barService: ExternerBarService,
    private http: HttpClient
  ) {}

  public async get<T>(url: string): Promise<T> {
    const headers = await this.barService.getHeaders();
    return this.http
      .get<T>(url, { headers })
      .toPromise();
  }
}
```

<figcaption>Die Ausgangslage: async Methode mir Promise</figcaption>

Begründet wurde die ungewohnte Schnittstelle damit, dass ein externer Service (im Beispiel `ExternerBarService`) zum Einsatz kam, der mit Promises arbeitete. Dies führte dazu, dass im eigenen Code `await` verwendet werden musste, um das Ergebnis des Promise abzuwarten. Um nicht ein Observable mit einem Promise im Bauch zu liefern, wurde anschließend das Observable des eigenen `httpClient`-Aufrufs in ein Promise umgewandelt. Dadurch musste sich zwingend auch das eigene API ändern: Die Methode erhielt als Rückgabewert ein Promise und musste mit `async` versehen werden.

## Wieso, es funktioniert doch?

Und wo liegt das Problem? Es funktioniert doch! Die Verwendung von Promises
im Angular-Kontext, der ansonsten die Rxjs-Library einsetzt, ist zumindest
gewöhnungsbedürftig. Trotzdem fände die Diskussion wahrscheinlich erst gar nicht statt, hätte dieser Service nicht von sämtlichen Projekten verwendet und darin in etlichen Komponenten eingesetzt werden müssen. Denn technisch spräche gegen Promises in Angular erstmal mal nichts, was ihre Verwendung gänzlich infrage stellen würde. Schließlich sind sie das asynchrone Werkzeug, das von Browsern nativ verstanden wird. Dennoch stoßen sie hier und da an ihre Grenzen und sind für manche Aufgaben einfach nicht genug – z.B. dann nicht, wenn mehrere Werte hintereinander emittiert werden müssen. Observables sind für viele Aufgaben einfach besser gewappnet. Ihre Schnittstelle erlaubt es, eine Vielzahl von Operatoren einzusetzen, um den emittierten Wert zu verarbeiten, zu transformieren oder auch Seiteneffekte auszulösen, ohne damit in eine Callback-Falle zu tappen. Warum also die Umstände, wenn es eine _"bessere"_ Alternative gibt?

## Die Alternative

Wie sehe die Alternative aus? Dass die externe Abhängigkeit auf Promises setzt, lässt sich nicht ändern – wir haben in seltenen Fällen Einfluss darauf. Was wir selbst in der Hand haben, ist unser eigener Code, also jener, in dem die Abhängigkeit verwendet wird. Ziel ist es daher, die Implementierungsdetails nach außen hin zu verbergen und die Schnittstelle den eigenen Ansprüchen und der Erwartungshaltung des Teams entsprechend zu gestalten: Wir wollen also keine asynchrone Methode bereitstellen, die einen Promise liefert, sondern eine, die einen Datenstrom, also ein Observable, zurückgibt und sich damit in Angular hürdenfrei einsetzen lässt.

Statt den Promise mit `await` abzuwarten und die Methode dadurch asynchron werden zu lassen, sollte der Aufruf des externen Services in ein Observable gekapselt werden. Stellt man es richtig an, so kommt der Promise erst dann zur Ausführung, wenn die aufrufende Stelle das zurückgelieferte Observable über ein `subscribe` abonniert.

```ts
//...
const headers$ = defer(() => from(this.barService.getHeaders()));
//...
```

<figcaption>Schritt 1: Den Promise in ein Observables kapseln</figcaption>

Hierzu bieten sich die Hilfsfunktionen [from](https://rxjs.dev/api/index/function/from) und [defer](https://www.learnrxjs.io/learn-rxjs/operators/creation/defer) aus der Rxjs-Library an. Das Util `from` konvertiert den übergebenen Promise in ein Observable, verhindert aber nicht, dass dieser gleich aufgelöst wird. Dies übernimmt das andere Util – `defer`. Diese Funktion nimmt einen Callback entgegen, das verspricht ein Observable zu liefern. Die Ausführung des Callbacks wird dabei so lange hingehalten, bis der Datenstrom über ein `subscribe` abonniert wurde.

Eine Frage bleibt noch offen: Wie greifen wir auf den tatsächlichen Wert in dem `headers$`-Observable zu? Denn schließlich wird dieser als Parameter für den nachgelagerten Request-Call benötigt. Es zu abonnieren, ergäbe keinen Sinn. Damit würden wir einerseits die Verwendung von `defer` obsolete machen und hätten andererseits nicht mehr die Möglichkeit selbst ein Observable zu liefern.

Der folgende Ansatz würde nicht funktionieren:

```ts
// Dies führt nicht zum gewünschten Ergebniss
headers$.subscribe((headers) => {
  // Das innere Observable wäre für den Aufrufer
  // nicht mehr zugängig
  this.http.get<T>(url, { headers });
});
```

<figcaption>Keine so gute Idee</figcaption>

Um es richtig anzustellen, müsste ein _flattening_-Operator verwendet werden, der das Ergebnis des `headers$`-Observable in ein weiteres Observable transformiert. Der Operator [`switchMap`](https://rxjs.dev/api/index/function/switchMap) kommt ins Spiel. Dieser wird, wie alle anderen Operatoren aus der Rxjs-Library, über die Methode [`pipe`](https://rxjs.dev/api/index/function/pipe) in die Verarbeitungskette des Datenstroms eingehängt. Er bekommt das Ergebnis des Datenstroms übergeben und liefert seinerseits ein Observable zurück. Der richtige Ansatz wäre also der Folgende:

```ts
headers$.pipe(
  switchMap((headers) => this.http.get<T>(url, { headers }))
);
```

<figcaption>Schritt 2: den switchMap-Operator verwenden</figcaption>

Die vollständige Umsetzung der fiktiven Methode sehe damit wie folgt aus:

```ts
// …
public get<T>(url: string): Observable<T> {
 const headers$ = defer(() => from(this.barService.getHeaders()));
 return headers$.pipe(
   switchMap((headers) => this.http.get<T>(url, { headers }))
 );
}
// …
```

<figcaption>Das Endergebnis – die gewohnte Schnittstelle</figcaption>

## Fazit

Die Schnittstelle des Services entspricht nun der Erwartungshaltung eines Angular-Entwicklers: Man stolpere nicht mehr über den Promise und habe die gewohnte Schnittstelle eines Observable. Wie bereits erwähnt, spricht technisch gesehen, nichts dagegen, einen Promise statt eines Observable zu verwenden, sofern es sich um eine einmalige Emission handle und nicht um ein Datenstrom, wie es z.B. bei einem Type-ahead-Konstrukt der Fall wäre. Und doch sollte man sich fragen, ob es sinnvoll ist, beide Ansätze innerhalb eines Projekts zu mischen, und ein weiteres Mal, wenn es sich um mehrere Projekte eines Mono-Repos handle. Denn es wird nicht lange dauern und ein weiterer Service wird eingeführt, in dem Promises verwendet werden – diesmal womöglich aus Gewohnheit und unbegründet. Der Konsens innerhalb des Projekts würde mit der Zeit leiden und das Projekt zu einer Code-Basis heranwachsen, in der keiner mehr mit Sicherheit sagen könnte, warum an so vielen Stellen ähnliche Aufgaben mit unterschiedlichen Ansätzen gelöst werden. Selbstverständlich kann es, wie in diesem Beispiel gezeigt, vorkommen, dass man aus Gründen nun doch mit Promises arbeiten muss. Dann gilt es aber, meiner Meinung nach, dies als Implementierungsdetail zu betrachten und es von der Außenwelt zu verbergen. Wie es geht, hat dieser Artikel hoffentlich zeigen können.


Um mit asynchronen Aufgaben umzugehen, werden in Angular üblicherweise Observables eingesetzt. Sollte an einigen Stellen trotzdem mit Promises gearbeitet werden, so wäre es vom Vorteil, ihre Verwendung an die Arbeitsweise des Frameworks anzupassen und sie in Observables zu kapseln. Wie es geht und was dabei zu beachten gilt, zeigt dieser Artikel.

... und wie man damit umgeht

Promises in Angular Services

Es gibt viele Notizen- und Schreib-Apps, die auf Markdown setzen — eine Auszeichnungssprache, der sich viele
Schreiberinnen und Schreiber bedienen, um
ihre Texte ohne Ablenkung verfassen zu können. Auch ich schreibe gern in einer App, die Markdown versteht
und mir somit den Fokus auf das Wesentliche ermöglicht.

Ich habe mich gefragt, wie solche Apps implementiert werden; wieviel Code muss ich heute noch selbst schreiben, wenn es
mittlerweile doch für nahezu jedes Problem eine Lösung in Form einer Bibliothek oder eines Frameworks gibt? Dieser Frage
bin ich nachgegangen und habe eine kleine App in [Svelte](https://svelte.dev) implementiert — einem Compiler für
optimierte Web-Apps, wie Rich Harris, der Erfinder des Frameworks, es zu sagen pflegt. Svelte soll in diesem Artikel
jedoch nicht im Vordergrund stehen, denn dazu gibt es bereits ein sehr gutes und
ausführliches [Tutorial](https://svelte.dev/tutorial/basics). Vielmehr sollte das Framework einen Rahmen für die App
bieten, in dem der Markdown-Editor entwickelt werden soll.

## Neues Projekt anlegen

Um ein neues Projekt in Svelte anzulegen, genügt ein einzelner Befehl in der Kommandozeile, dem wir als Parameter das zu
beziehende [Svelte-Template](https://github.com/sveltejs/template) und den gewünschten Projektnamen übergeben. So
einfallsreich wie ich bin, nenne ich das Projekt `markdown-editor`.

```bash
npx degit sveltejs/template markdown-editor
```

Das Programm `degit` kopiert den letzten Stand des `sveltejs/template` Repository und legt ihn im angegebenen
Verzeichnis ab. Im Vergleich zu `clone` läuft der Befehl viel schneller ab, weil hierbei nicht die gesamte Git-History
heruntergeladen wird. Ist der Download abgeschlossen, können wir in das eben angelegte Verzeichnis wechseln und die
Abhängigkeiten des Projekts installieren:

```bash
cd markdown-editor
npm install
```

Die Anwendung kann anschließend mit dem folgenden Kommando im Entwicklungsmodus gestartet werden:

```bash
npm run dev
```

## CSS aus Fremdbibliotheken importieren

Da wir uns den Aufwand das Rad neu zu erfinden sparen und im Projekt deshalb Fremdbibliotheken einsetzen wollen, sollte
auch das Einbinden von Assets dieser Ressourcen konfiguriert werden. Für den Import von JavaScript müssen wir nichts
weiter tun: hier können wir wie üblich mit ES-Modulen arbeiten und den Code über die Import-Anweisungen laden. Bei
Stylesheets hingegen sieht die Sache etwas anders aus: hier bedarf es noch einer kleinen Konfiguration, damit das CSS
von Drittanbietern importiert und gebündelt werden kann.

Als _Module-Bundler_ wird in Svelte per Default [Rollup](https://rollupjs.org/guide/en/) eingesetzt, auch wenn die
Integrationen anderer _Bundler_ wie Webpack möglich ist. Für Rollup wird das Plug-in `rollup-plugin-css-only` benötigt,
um das in Komponenten importierte CSS in eine einzige Datei zu bündeln.

```bash
npm install --save-dev rollup-plugin-css-only
```

Nach der Installation muss das Plug-in in der `rollup.config.js` importiert und konfiguriert werden, wobei sich die
Konfiguration lediglich auf die Festlegung des Zielverzeichnisses beschränkt:

```js
...
// Plug-in importieren
import css from 'rollup-plugin-css-only';

...

// und in plugins konfigurieren:
export default {
    ...
    plugins: [
       css({output: 'public/build/libs.css'}),
       ...
    ]
    ...
} 
```
<figcaption>Datei: rollup.config.js</figcaption>

Es bleibt noch die Anpassung der `index.html` im Verzeichnis `/public`: Das gebündelte Stylesheet `libs.css` muss im
Head eingebunden werden; es sollte in der Reihenfolge vor dem eigenen CSS liegen, um Überschreibungen zu ermöglichen.

```html
...

<link rel="stylesheet" href="/build/libs.css">


<link rel='stylesheet' href='/global.css'>
<link rel='stylesheet' href='/build/bundle.css'>
...
```
<figcaption>Datei: /public/index.html</figcaption>

Nun ist es möglich in unseren Svelte-Komponenten mit der `import`-Anweisung CSS aus NPM-Paketen zu importieren.

## Die passende Fremdbibliothek finden

Auf der Suche nach einer passenden Library, bin ich auf mehrere fertige Lösungen für Editoren gestoßen, in denen mittels
Markdown Text eingegeben werden konnte. Nennenswert wäre hier z. B.
der [EasyMDE Markdown Editor](https://www.npmjs.com/package/easymde "EasyMDE Markdown Editor"). Er ist vollständig in
JavaScript implementiert und stellt neben der Eingabe mittels Markdown, eine Toolbar bereit, mit deren Hilfe der Text
zusätzlich formatiert werden kann. Bei der Eingabe hat man auch direkt das visuelle Feedback der Syntax: die
Überschriften werden größer, betonte Wörter kursiv oder fett dargestellt und Links wie üblich unterstrichen. Diese
Lösung würde sich hervorragend für dedizierte Eingabebereiche in einer Anwendung eignen, für unser Vorhaben — einer Art
Notizen App — wäre es jedoch unpassend, weil wir lediglich an dem Eingabebereich interessiert sind. Interessant war
jedoch die Tatsache, dass diese Implementierung als auch einige andere zusammen den gleichen Unterbau nutzen: sie alle
verwenden die Library [CodeMirror](https://codemirror.net).

## CodeMirror

CodeMirror ist in puncto Editor ein Alleskönner. Die Library ersetzt eine einfache `<textarea>` durch einen Editor und
stellt eine [umfangreiche API](https://codemirror.net/doc/manual.html#api) für die Verarbeitung der Eingabe zur
Verfügung. Sie bietet außerdem unzählige Modi für das Highlighting unterschiedlicher Programmier- und
Auszeichnungssprachen, mitunter auch Markdown. Auch der [REPL-Editor](https://svelte.dev/repl/hello-world) auf der
Svelte-Tutorial Seite setzt unter der Haube CodeMirror ein, was für mich ein gutes Zeichen war, um mir die Library etwas
näher anzusehen. Gesagt, getan: wir installieren CodeMirror mit dem folgenden Befehl:

```bash
npm install codemirror
```

Im Projektverzeichnis legen wir eine neue Svelte-Datei an, in der wir den Editor implementieren werden, `Editor.svelte`.
Als Erstes importieren wir die erforderlichen Abhängigkeiten von CodeMirror: das grundlegende CSS und das JavaScript für
den Markdown-Modus, sowie die Factory `CodeMirror`.

```html

<script>
    import 'codemirror/lib/codemirror.css';
    import 'codemirror/mode/markdown/markdown';
    import CodeMirror from 'codemirror';
</script>
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Das Template für den Editor ist sehr überschaubar:

```html

<div class="editor-container">
    <textarea></textarea>
</div>
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Dem `div` verpassen wir noch eine CSS-Klasse, um es im `style`-Tag selektieren und formatieren zu können. Da wir hier
nun einen `div` haben werden und in Svelte die CSS-Kapselung auf Komponentenebene gilt, könnten wir genauso gut auf die
CSS-Klasse verzichten und den `div` direkt über den Element-Selektor selektieren. Mein innerer Monk besteht jedoch
darauf die Dinge von vornherein richtig zu benennen, um sie beispielsweise auch im `style`-Tag später besser zuordnen zu
können.

Die `textarea` wird außerdem mit der _Property_ `value` verknüpft: Somit schaffen wir die Möglichkeit einen Text von
außen, beim Benutzen der Komponente, zu setzen und ihn wieder auszulesen, wenn er im Editor bearbeitet wurde. Als
Defaultwert setzen wir eine leere Zeichenkette.

```html

<script>
    ...
    export let value = '';
</script>

...
<textarea {value}></textarea>
...
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Weil das `textarea` Attribut und die _Property_ `value` gleich benannt sind, können wir hier von der Kurzform des _
Property-Bindings_ profitieren. Statt `value={value}`, kann einfach nur `{value}` geschrieben werden.

Für die Initialisierung des Editors wird eine Referenz auf das DOM-Element der `textarea` benötigt. Dies ist mit der
Direktive `bind:this` ein Kinderspiel:

```html

<script>
    ...
    export let value = '';
    let textArea;
</script>

...
<textarea bind:this={textArea} {value}></textarea>
...
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Der Zugriff auf die Referenz wird jedoch erst dann möglich sein, wenn die Komponente in das DOM eingebunden wurde. In
Svelte kann dafür die Lebenszyklus-Funktion `onMount` benutzt werden, die den übergebenen _Callback_ dann ausführt, wenn
die Komponente vollständig geladen wurde.

```html

<script>
    ...
    import {onMount} from 'svelte';

    export let value = '';
    let textArea;

    onMount(() => {
        // erst hier kann auf die Referenz zugegriffen werden
        const editor = CodeMirror.fromTextArea(textArea);
    });
</script>
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Nun müssen wir auch dafür sorgen, dass keine Speicherlecks entstehen, wenn die Komponente wieder gelöscht wird: Die
Editor-Instanz muss dann mit allen ihren _Event-Listenern_ und _Handlern_ vernichtet werden, was durch den Aufruf der
Methode `toTextArea()` erfolgt. Für diese Zwecke kann in Svelte die weitere Lebenszyklus-Funktion `onDestroy` benutzt
werden, die einen _Callback_ registriert und ihn dann aufruft, wenn die Komponente aus dem DOM wieder entfernt wird. Ein
solcher _Callback_ kann auch direkt als Rückgabewert der an die `onMount` übergebenen _Arrow-Function_ definiert werden.

```javascript
onMount(() => {
    const editor = CodeMirror.fromTextArea(textArea);
    // onDestroy-Callback zurückgeben
    return () => editor.toTextArea();
}); 
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Mit diesem Ansatz schlagen wir zwei Fliegen mit einer Klappe: Variablen müssen nicht im Geltungsbereich außerhalb
von `onMount` deklariert werden, um sie in `onDestroy` wieder verwenden zu können; und der zusammengehörende Code wird
nicht unnötig auseinander gezogen.

Als Nächstes muss der Editor konfiguriert werden. Wir können der Factory-Methode `fromTextArea` noch ein
Konfigurationsobjekt als zweites Argument mitgeben. Über dieses können sämtliche Einstellungen am Editor vorgenommen
werden; uns interessieren allerdings nur zwei davon:

- `mode`, die Einstellung der Programmier- bzw. Auszeichnungssprache im Editor. Wir wollen den Modus Markdown verwenden
  und würden hier entsprechend `markdown` angeben.
- `lineWrapping`, die Einstellung des automatischen Zeilenumbruchs. Wird `true` angegeben, so erfolgt automatisch ein
  Zeilenumbruch am Rand des Editors, bei `false` können hingegen Zeilen über die durch den äußeren Container definierte
  Breite hinauswachsen, sodass dann horizontal gescrollt werden muss.

```js
onMount(() => {
    const editor = CodeMirror.fromTextArea(textArea, {
        lineWrapping: true,
        mode: 'markdown',
    });
    editor.focus();
    return () => {
        editor.toTextArea();
    }
});
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Mit dem Aufruf `editor.focus()` verbessern wir zusätzlich die User Experience: unsere Endnutzer werden nach dem Öffnen
der App direkt mit dem Schreiben loslegen können und werden nicht gezwungen, vorher in den Schreibbereich reinzuklicken.

## CSS Anpassungen

Auch wenn wir den Editor jetzt schon verwenden und die Syntax einzelner Strukturelemente im Text erkennen könnten, so
wäre es doch ganz nett, wenn die Überschriften nicht nur fett markiert, sondern sich auch größer darstellen würden als
der restliche Text. Diese Anpassung können wir im `<style>`-Tag der Komponente vornehmen.

```html
<style>
    .editor-container :global(.cm-header) {
        color: black;
    }

    .editor-container :global(.cm-header-1) {
        font-size: 200%;
    }

    .editor-container :global(.cm-header-2) {
        font-size: 150%;
    }

    .editor-container :global(.cm-header-3) {
        font-size: 120%;
    }
</style>
```
<figcaption>Datei: /src/Editor.svelte</figcaption>

Das CodeMirror CSS hat, obwohl es in die Komponente importiert wurde, immer noch eine globale Geltung und kann nur
mithilfe des Modifikators `:global()` überschrieben werden. Würden wir bei den CodeMirror CSS-Klassen auf die Angabe des
Modifikator verzichten, so würde das Framework sie als Komponenten-eigene interpretieren und sie, wegen der
CSS-Kapselung auf Komponentenebene, mit einem Hash versehen: Dadurch würden wir neue Klassen definieren, anstatt
bestehende zu überschreiben. Da wir mit der Angabe von `:global()` die CSS-Kapselung ausgehobelt haben, ergibt es Sinn
zusätzlich eine eigene CSS-Klasse als Vorfahren-Selektor zu benutzen, um Konflikte mit anderen Komponenten vorzubeugen.
So können wir die Farbe für alle Überschriften festlegen und die Größe einzelner `.cm-header-*` anpassen. Zusätzlich
geben wir dem Container noch ein paar nette Formatierungen mit und passen auch die Darstellung des Cursors an:

```html
<style>
    ...
    .editor-container {
        margin: 2rem auto 0;
        width: 800px;
        padding: 2rem;
        background: white;
        border-radius: 0.5rem;
        box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
    }

    .editor-container :global(.CodeMirror-cursor) {
        border-left: 2px solid rgb(26, 154, 240);
    }
</style>
```

Der Container kriegt abgerundete Ecken, eine feste Breite zugewiesen, einen weißen Hintergrund und wird durch eine
leichte Schattierung von umgebender Fläche abgesetzt. Dem Cursor geben wir eine Breite von 2 Pixeln und färben ihn in
ein schönes Blau ein. Damit lässt sich zwar noch keine Waschmaschine gewinnen, verstecken muss sich der Editor aber nun
auch nicht mehr:

![](../../assets/images/blog/md-editor.png)
<figcaption>Der fertige Markdown Editor</figcaption>

Die Komponente Editor ist fertig und kann in andere Komponenten oder wie in unserem Fall in die Hauptkomponente `App`
eingebunden werden:

```html
<script>
    import Editor from './Editor.svelte';

    let value = '# FooBar';
</script>

<main>
    <Editor value={value}></Editor>
</main>
```
<figcaption>Datei: /src/App.svelte</figcaption>

## Fazit

Nun kann ich die initial gestellte Frage damit beantworten, dass es tatsächlich kaum Code geschrieben werden musste, um
einen lauffähigen Markdown-Editor zu erhalten. Die Library des In-Browser-Code-Editors ist sehr mächtig, hat viele
Konfigurationsmöglichkeiten, wird laufend weiterentwickelt und lässt sich mit sehr wenig Aufwand in ein Framework wie
Svelte integrieren. Für andere Frameworks gibt es bereits fertige _Wrapper_, die als NPM-Pakete bezogen werden können:
Zu nennen sind hier z. B. [ngx-codemirror](https://www.npmjs.com/package/@ctrl/ngx-codemirror "ngx-codemirror") für
Angular und [react-codemirror2](https://www.npmjs.com/package/react-codemirror2) für React. Ich werde CodeMirror auf
jeden Fall weiter im Auge behalten und die Library auch in anderen Projekten, die einen Editor benötigen, in Betracht
ziehen.

Die beispielhafte Implementierung aus diesem Artikel befindet sich wie immer
auf [Github](https://github.com/lukaskorten/code-snacks-examples/tree/master/svelte/markdown-editor).

Welche Library eignet sich für die Implementierung eines Markdown-Editors am besten und wie lässt sich diese in eine Svelte-Komponente einbinden.

Markdown Editor in Svelte umsetzen

Eine Einführung in das leichtgewichtige JavaScript-Framework Svelte.

der leichtgewichtige Compiler für performante Webanwendungen

Svelte

In diesem Artikel zeige ich, wie eine WebComponent entwickelt und in Wicket – ein auf Java basiertes Server-Side-Rendering Webframework – integriert werden kann.

WebComponents in einem Java Webframework einsetzen

Bei langlaufenden iterativen Prozessen ist es häufig nützlich den aktuellen Fortschritt ablesen zu können. Die Angaben
innerhalb eines Inkrements in jeweils einer neuen Zeile auszugeben ist zwar ein denkbarer Ansatz, führt aber dazu, dass
der Log schnell überflutet wird. Dadurch können andere wichtige Ausgaben verdrängt werden. Was man stattdessen bräuchte,
ist eine einzige Zeile, die sich fortlaufend aktualisiert und somit immer den aktuellen Fortschritt der Verarbeitung anzeigt. In diesem
Artikel zeige ich, wie eine solche Ausgabe unter Verwendung der Slf4J-API umgesetzt werden kann.

Der Beispielcode für diesen Artikel
befindet sich auf [GitHub](https://github.com/lukaskorten/code-snacks-examples/tree/master/spring-boot/progress-log).

## Idee

Die Idee ist simple: Einen Marker definieren, der in den Log-Anweisungen des Fortschritts verwendet werden soll; für
diesen Marker einen Appender in der `logback-spring.xml` deklarieren und ihm ein benutzerdefiniertes Pattern zuweisen,
das am Ende anstatt des Steuerzeichens `\n` für einen Zeilenumbruch, das Zeichen `\r` für den Wagenrücklauf (engl.
Carriage Return - CR) enthält. Die Schreibmarke würde damit nach jeder Ausgabe wieder an den Zeilenanfang springen und
den bisherigen Inhalt mit der nächsten Ausgabe überschreiben.

Eine Ausgabe, die wir uns dadurch erhoffen, soll in etwa die folgende Struktur aufweisen:

```bash
...
2020-08-27 06:57:12,914 INFO - start process ...
                5161 ms INFO - PROGRESS: 45 / 100 items processed ...
...
```

```bash
...
2020-08-27 06:57:12,914 INFO - start process ...
2020-08-27 06:57:23,232 INFO - process finished: 100 items processed
...
```

Eine Ausgabe am Beginn der Verarbeitung, eine sich fortlaufend aktualisierende Zeile mit dem Fortschritt und eine am
Ende, wenn die Verarbeitung abgeschlossen ist.

## Appender konfigurieren

Die Definition des Appenders in der `logback-spring.xml` könnte, wie folgt aussehen (Die Package-Namen in den `class`
Attributen wurden der Lesbarkeit halber gekürzt):

```xml

<appender name="progressAppender" class="...ConsoleAppender">
    <filter class="...EvaluatorFilter">
        <evaluator class="...OnMarkerEvaluator">
            <marker>PROGRESS</marker>
        </evaluator>
        <onMismatch>DENY</onMismatch>
        <onMatch>ACCEPT</onMatch>
    </filter>
    <encoder class="...PatternLayoutEncoder">
        <pattern>
            %20r ms %highlight(%level) - %marker: %green(%msg)\r
        </pattern>
    </encoder>
</appender>
```

Der im Appender angegebene Filter fängt alle Logausgaben ein, die mit dem Marker `PROGRESS` gekennzeichnet werden:
Z.B.: `LOG.info(progressMarker, „My message...“)`. Diese Ausgaben werden durch ein Layout-Pattern formatiert, das im
Gegensatz zum Default kein `\n` am Ende aufweist. Stattdessen wird das Steuerzeichen `\r` verwendet, um die Schreibmarke
an den Zeilenanfang springen zu lassen.

Das Layout-Pattern ist im `encoder`-Tag angegeben. Die im Layout-Pattern verwendeten Schlüsselwörter haben die folgende
Bedeutung:

- `%20` - ein Formatmodifikator, mit dem die Breite des Feldes und der rechte Blocksatz angegeben werden: So lässt sich
  die Dauer des Fortschritts rechtsbündig mit der Angabe der Uhrzeit im restlichen Log anordnen
- `r` - gibt die verstrichene Zeit in Milisekunden aus
- `%green(...)` - stellt den als Parameter angegebenen Inhalt in Grün dar
- `%highlight(...)` - hebt den als Parameter angegeben Inhalt hervor
- `%marker` - Schlüsselwort für die Ausgabe des verwendeten Markers
- `%msg` - Die eigentliche Nachricht der Loganweisung

Die vollständige Definition der logback-spring.xml
kann [hier](https://github.com/lukaskorten/code-snacks-examples/blob/master/spring-boot/progress-log/src/main/resources/logback-spring.xml)
eingesehen werden.

## Verwendung im Code

Um das Beispiel möglichst kurz zu halten, werden wir uns hier einer einfachen Schleife bedienen:

```java
LOG.info("start process ...");

Marker progress = MarkerFactory.getMarker("PROGRESS");
for (int i=0; i<=100; i++) {
    LOG.info(progress, "items processed - {} / {}", i, 100);
    Thread.sleep(100);
}

LOG.info("process finished.");
```

Als erstes brauchen wir einen Marker, um unsere Loganweisungen mit dem konfigurierten Appender zu verknüpfen. Wir lassen
uns von der `MarkerFactory` einen Marker mit dem Bezecihner `PROGRESS` erzeugen, der in der Logger-Konfiguration
festgelegt wurde.

Jede Iteration soll stellvertretend für einen Schritt innerhalb eines langlebigen Prozesses stehen: Um die
Verarbeitungsdauer eines Schritts zu simulieren, lassen wir den aktuellen Prozess mit `Thread.sleep(100)` für einen
Augenblick anhalten. Anschließend loggen wir den aktuellen Fortschritt, in dem wir den Marker `progress` an die
Log-Anweisung übergeben:

```java
LOG.info(progress,"items processed - {} / {}",i,100);
```

## Fazit

Die vorgestellte Lösung hat noch ein dickes "aber": Sie funktioniert nur dann, wenn die Fortschrittsinformation die
einzige Logsausgabe innerhalb des Teilschritts darstellt, die auf `System.out` schreibt. Weiteres Logging würde die
Zeile des Fortschritts überschreiben und am Ende einen Umbruch (`\n`) einfügen - die ganze Mühe wäre umsonst gewesen. Es
wäre jedoch bedenklich, weitere Ausgaben in das gleiche `target` zu schreiben, weil auch diese bei länger laufenden
Prozessen den Log vollschreiben und andere Ausgaben verdrängen würden. Vielmehr könnte es Sinn ergeben,
einen [FileAppender](http://logback.qos.ch/manual/appenders.html#FileAppender) zu definieren und die relevante
Informationen oder Warnungen in eine Datei auszugeben.

Eine Fortschrittsanzeige in Logausgaben mit Slf4J implementieren.

Fortschritt in Logausgaben

Es gibt viele Gründe um den in einem Test angehäuften Datenstand vor der Ausführung des nachgelagerten Tests
aufzuräumen. Vermutlich gibt es auch ebensoviele Ansätze, um dieses Ziel zu erreichen. In diesem Beitrag zeige ich, wie
eine Datenbank vor jedem Test mit Hilfe einer JUnit5-Extension auf ihren initialen Stand gebracht werden kann.

## DataJpaTest

Wenn die Anwendung die Implementierung eigener Query-Methoden in einem Spring Data JpaRepository erfordert, dann erweist
sich das Setup für die entsprechenden Tests als besonders leichtgewichtig. Hierfür liefert das Framework die
Annotation `@DataJpaTest`, die eine speziell auf JPA-Tests zugeschnittene Autokonfiguration des Application-Contexts
bereitstellt. Sie sorgt dafür, dass in diesen Tests nur die JPA relevanten Komponenten initialisiert werden und nicht
der gesamte Application Context hochgefahren wird. Die in den Tests erzeugten Daten werden nach jedem Lauf automatisch
entfernt, sodass der nachfolgende Test mit einer leeren Datenbank starten kann.

```java

@DataJpaTest
public class UserRepositoryTest {

    @Autowired
    UserRepository userRepository;

    @Test
    void saveUser() {
        userRepository.save(new User("Jane", "Doe"));
        assertThat(userRepository.findAll()).hasSize(1);
    }
}
```

## SpringBootTest

Ein anderes Bild ergibt sich hingegen, wenn ein Integrationstest implementiert werden muss, in dem ein oder mehrere
Spring gemanagte Services verwendet werden.

Die Annotation `@DataJpaTest` wäre in diesem Fall nicht zielführend, da sie die mit `@Service` oder `@Component`
annotierten Klassen ignorieren würde. Stattdessen wäre in diesem Fall die Annotation `@SpringBootTest` die richtige
Wahl, um den vollständigen (oder auch eingeschränkten) Application-Context hochzufahren.

Bei solchen Tests könnten jedoch Seiteneffekte entstehen, da alle Tests auf dem gleichen Schema der im Test verwendeten
Datenbank arbeiten. So kann z.B. in einem Test ein neuer Benutzer angelegt werden, auf den auch im nachgelagerten Tests
zugegriffen werden kann. Dass dadruch Kollisionen entstehen können ist offensichtlich. Die Testergebnisse werden fragil
und nicht mehr zuverlässig.

Bei solchen Tests muss sichergestellt werden, dass deren Ausgangslage immer dieselbe ist. Die Datenbank muss demzufolge
vor jeder Testausführung auf ihren initialen Zustand zurückgesetzt werden.

### Die Datenbank leeren

Was wir brauchen ist also einer Art Aufräumkommando für die Datenbank. Das kann z.B. ein Service sein, der die Datenbank
über `deleteAll()-`Aufrufe auf entsprechenden JpaRepositories leert. Im folgenden Listing wird ein solcher Service
implementiert, in dem die Datensätze aus dem `UserRepositry` entfernt werden. Gäbe es im Projekt andere Jpa-Entities,
die mit `User` in einer `@ManyToOne` oder `@OneToOne` Beziehung stünden, so müsste das Leerräumen dieser Repositories
entsprechend vorgezogen werden. Bei diesem Beispiel gehen wir jedoch nur von einer Entity aus, so dass keine
weiteren `deleteAll()`-Aufrufe erforderlich sind.

```java

@Service
@AllArgsConstructor
@FieldDefaults(level = AccessLevel.PRIVATE, makeFinal = true)
public class DbCleanUpService {

    UserRepository userRepository;

    void cleanUp() {
        userRepository.deleteAll();
    }
}
```

Das Aufräumen der Datenbank in einen Service auszulagern ist insofern sinvoll, als dass wir dadurch nur eine Stelle
anzupassen haben, wenn Änderungen am Schema vorgenommen werden. Würden wir stattdessen die einzelnen Repository-Aufrufe
jeweils in das Set-up (eine mit `@BeforeEach` annotierte Methode im Test) eines jeden Integrationstests auslagern, so
hätten wir anschließend einen erhebllich höheren Aufwand all diese Stellen zu ändern.

Stattdessen könnten wir in das Set-up eines jeden Tests den Aufruf des neuen Aufräum-Services einfügen. Besser wäre
jedoch die Implementierung einer Extension, die unsere Tests um dieses Verhalten erweitern würde.

### JUnit5 Extension

Eine Extension in JUnit5 ist mit einer Rule in JUnit4 vergleichbar - sie kann einen Test um ein gewünschtes Verhalten
bzw. Logik erweitern. Abhängig von dem, an welcher Stelle im Lebenszyklus eines Tests eingegriffen werden soll, müssen
entsprechende Callback-Interfaces implementiert werden. Möchte man z.B. eine bestimmte Logik unmittelbar vor der
Ausführung des Tests aufrufen, so kann das Interface `BeforeEachCallback` implementiert werden. Eine komplette Liste
aller Callbacks samt ihrer Beschreibung
kann [hier](https://junit.org/junit5/docs/current/user-guide/#extensions-lifecycle-callbacks) nachgeschlagen werden.

```java
public class MyExtension implements BeforeEachCallback {

    @Override
    public void beforeEach(ExtensionContext context) {
        // ...
    }
}
```

### Zugriff auf den ApplicationContext

Interessant wird es, wenn innerhalb einer Extension auf den `ApplicationContext` zugegriffen werden soll, um sich z.B.
den `DbCleanUpService` geben zu lassen. Dafür kann die Hilfsfunktion `getApplicationContext` der
Klasse `SpringExtension` genutzt werden. Als Parameter muss ihr der `ExtensionContext` übergeben werden, der in jeder
Callback-Methode zur Verfügung steht. Die geeignete Stelle für den Zugriff auf die von Spring gemanagte Beans, liegt vor
der Ausführung aller Testmethoden einer Test-Klasse. Wir können also den `BeforeEachCallback` verwenden, um unseren
Service aus dem `ApplicationContext` zu holen und ihn in einer Instanzvariable abzulegen. Anschließend kann
im `BeforeEachCallback` auf den `DbCeanUpService` zugegriffen und die Datenbank über den  `cleanUp()`-Aufruf auf den
initialen Stand gebracht werden.

```java
public class DbCleanUp implements BeforeAllCallback, BeforeEachCallback {

    private DbCleanUpService cleanUpService;

    @Override
    public void beforeAll(ExtensionContext context) {
        ApplicationContext ac =
                SpringExtension.getApplicationContext(context);
        cleanUpService = ac.getBean(DbCleanUpService.class);
    }

    @Override
    public void beforeEach(ExtensionContext context) {
        cleanUpService.cleanUp();
    }
}
```

Nun steht noch die Anwendung der implementierten Extension aus. Alles was wir brauchen, um einen Test mit dem
Aufräumverhalten auszustatten, ist das Annotieren der Test-Klasse mit `@ExtendWith(DbCleanUp.class)`. Fertig, vor jedem
Testlauf wird nun die Datenbank geleert - die Tests haben keine Seiteneffekte mehr und können in beliebiger Reihenfolge
ausgeführt werden.

```java

@ExtendWith(DbCleanUp.class)
@SpringBootTest
public class IntegrationTestA {

    @Autowired
    private UserService userService;

    @Test
    void saveUser() {
        userService.saveUser(new UserDTO("John", "Doe"));
        assertThat(userService.count()).isEqualTo(1);
    }
}
```

Auf [Github](https://github.com/lukaskorten/code-snacks-examples/tree/master/spring-boot/dbcleanup) habe ich hierzu ein
kleines Projekt vorbereitet, in dem der gesamte Code aus diesem Post enthalten ist. Zusätzlich ist dort auch ein
weiterer Integrationstest hinterlegt, mit dem die Seiteneffekte des Test-übergreifenden Datenbankzustands nachvollzogen
werden können. Beide Integrationstests setzen die hier beschriebene `DbCleanUp`-Extension ein. Die
Annotation `@ExtendWith(...)` kann vorübergehend entfernt werden, um die hier beschriebenen Seiteneffekte zu sehen.

## Links

- [Github-Projekt DbCleanUp Extension](https://github.com/lukaskorten/code-snacks-examples/tree/master/spring-boot/dbcleanup)
- [DataJpaTest Dokumentation](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-testing-spring-boot-applications-testing-autoconfigured-jpa-test)
- [SpringBootTest Dokumentation](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-testing-spring-boot-applications)
- [JUnit5 Extensions](https://junit.org/junit5/docs/current/user-guide/#extensions)
- [JUnit5 Extension Lifecycle Callbacks](https://junit.org/junit5/docs/current/user-guide/#extensions-lifecycle-callbacks)


Wie kann eine Datenbank vor jedem Test mit Hilfe einer JUnit5-Extension auf ihren initialen Stand gebracht werden?

Datenbank mit einer JUnit5 Extension leeren

In diesem Post zeige ich am Beispiel einer MariaDB, wie eine Datenbank mit wenig Aufwand in einem Docker Container
installiert und für die Nutzung in einer Spring-Boot Applikation bereitgestellt werden kann.

## Docker installieren

Als erstes muss sichergestellt werden, dass auf dem aktuellen System eine Dockerinstallation vorhanden ist. Sofern man
sich nicht auf einem Linux-System bewegt, muss Docker über eine Installationsdatei, die für Windows oder Mac OS
von  [www.docker.com](https://www.docker.com/get-started) bezogen werden kann, installiert werden. Ob eine Installation
vorhanden ist und in welcher Version sie vorliegt, kann über den Kommandozeilenbefehl `docker --version` herausgefunden
werden.

```bash
> docker --version
Docker version 19.03.8, build afacb8b
```

## Starten einer neuen MariaDB Instanz

Mit dem Befehl `docker run` können neue Docker Container aus einem Image erzeugt und gestartet werden. So kann z.B. das
Image `mariadb` genutzt werden, um eine neue MariaDB Instanz zu initialisieren und sie in einem Docker Container laufen
zu lassen.

```bash
> docker run --name codesnacks-db -e MYSQL_ROOT_PASSWORD=geheim -d mariadb:10.2
```

Das [mariadb Image](https://hub.docker.com/_/mariadb) wird dabei automatisch von Docker Hub heruntergeladen, wenn es
nicht bereits auf dem lokalen Rechner verfügbar ist. Über den Parameter `-e` können Umgebungsvariablen des Containers
gesetzt werden. So kann z.B. das Passwort für den Root-User über die Umgebungsvariable `MYSQL_ROOT_PASSWORD` angeben
werden.

## Auf die Datenbank zugreifen

Sollte man auf den im Docker Container laufenden MariaDB-Server zugreifen wollen, so kann dies mit den folgenden zwei
Befehlen bewerkstelligt werden. Der Erste öffnet eine Bash innerhalb des Containers:

```bash
> docker exec -it codesnacks-db bash
```

Der zweite Befehl sorgt dafür, dass man sich mit der MariaDB als Root-User verbindet. Anschließend kann z.B. ein
SQL-Statement abgefeuert werden um ein neues Schema anzulegen.

```bash
> mysql -uroot -p
# passwort eingeben
```

## Docker Compose

Noch einfacher ist die Verwendung einer `docker-compose.yml`, in der sowohl die Angaben zum Image und dem für die Daten
benötigten Volume, als auch der Datenbank-spezifischen Umgebungsvariablen festgelegt werden können. In dieser Datei wird
eine MariaDB als Service deklariert, der über entsprechende Befehle gestartet und wieder beendet werden kann. Docker
Compose ist sehr mächtig und eignet sich vor allem für den Einsatz mehrererer Services, die gleichzeitig bzw. in einer
bestimmten Reihenfolge hochgefahren werden müssen. Diese Services sind in ihren eigenen Docker Containern gekapselt und
kommunizieren nur über exponierte Ports miteinander.

Auch wenn es sich bei diesem Beispiel nur um einen einzigen Service handelt und der Einsatz von Docker-Compose auf den
ersten Blick als übertrieben erscheinen mag, so überzeugt meiner Ansicht nach dennoch die Lesbarkeit einer YML-Datei und
die Anwendung des Patterns "Write Once, Use Often". Die `docker-compose`-Datei für das obige Beispiel könnte wie folgt
definiert werden:

```yaml
version: '3.4'
services:
  codesnacks_db:
    image: mariadb:10.2
    environment:
      MYSQL_ROOT_PASSWORD: geheim
      MYSQL_DATABASE: codesnacks
      MYSQL_USER: codesnacks
      MYSQL_PASSWORD: geheim
    restart: always
    ports:
      - '3306:3306'
    expose:
      - '3306'
    volumes:
      - codesnacks_db:/var/lib/mysql
volumes:
  codesnacks_db: { }
```

Die `docker-compose.yml` wird im Hauptverzeichnis des Projekts abgelegt und kann über die Befehle `docker-compose up`
und `docker-compose stop` gestartet und wieder beendet werden. Führt man also die oben definierte docker-compose.yml
mit `docker-compose up` aus, dann wird das MariaDB-Image in der Version 10.2 heruntergeladen, daraus ein Docker
Container erzeugt und gestartet. Anschließend kann auf die Datenbank, wie zuvor beschrieben, zugegriffen werden.

## Konfiguration in Spring-Boot

Auf eine MariaDB oder auch eine andere MySQL-Implementierung kann in Java über den MySQL Java Connector zugegriffen
werden. Die URL für die in der docker-compose definierten Datenbank lautet `jdbc:mysql://localhost:3306/codesnacks`. Die
Datenbank kann also in einer Spring-Boot-Anwendung über die folgenden Angaben in der `application.yml` zugegriffen
werden:

```yaml
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/codesnacks
    username: codesnacks
    password: geheim
    driverClassName: com.mysql.cj.jdbc.Driver
  jpa:
    hibernate:
      ddl-auto: update
    properties:
      hibernate:
        dialect: org.hibernate.dialect.MariaDBDialect
```

Mit dieser Konfiguration baut eine Spring-Boot Applikation beim Starten eine Verbindung zu der im Docker Container
liegenden Datenbank auf und legt ggf. ein über JPA oder entsprechende Migrationsskripte definiertes Schema in der
Datenbank an.

Auf [Github](https://github.com/lukaskorten/code-snacks-examples/tree/master/spring-boot/docker-mariadb) habe ich als
Beispiel ein kleines Spring Boot Projekt angelegt, das beim Starten die Verbindung zu der im docker-compose definierten
Datenbank aufbaut. Die docker-compose.yml ist im Hauptverzeichnis des Projekts abgelegt. Sie enthält die oben
beschriebene Konfiguration und muss vor dem Start der Anwendung über `docker-compose up` ausgeführt werden.

## Links

- [Docker herunterladen](https://www.docker.com/get-started)
- [Docker Compose](https://docs.docker.com/compose/)
- [MariaDB Image](https://hub.docker.com/_/mariadb)
- [Beispielprojekt](https://github.com/lukaskorten/code-snacks-examples/tree/master/spring-boot/docker-mariadb)


In diesem Post zeige ich am Beispiel einer MariaDB, wie eine Datenbank mit wenig Aufwand in einem Docker Container installiert und für die Nutzung in einer Spring-Boot Applikation bereitgestellt werden kann.