Von Tobias Reich publiziert am 1. August 2018

Effizientes Entwickeln von Komponenten dank Malvid

Als Frontend-Entwickler gibt es nichts Ärgerlicheres, als die Kontrolle über den HTML-Code zu verlieren, nachdem dieser im Backend implementiert wurde. Das passiert typischerweise, wenn der HTML-Code nicht zwischen Front- und Backend geteilt wird. 

Dass das so ist, ist nicht die Schuld des Backend-Entwicklers. Das Problem liegt im Frontend, welches keine gute Integration in das angestrebte CMS ermöglicht. Unsere Mission bei comwrap war es, dieses Problem zu lösen.

atomic-design-by-brad-frostAtomic Design erklärt von Brad Frost (© Brad Frost)

Das Problem

Unser bestehender Workflow folgte einem Muster, das es uns ermöglichte, das Frontend zu entwickeln, ohne uns zu sehr um seine spätere Verwendung zu kümmern. HTML, CSS und JS waren nicht an ein bestimmtes CMS gebunden. Die Nutzung einer anderen Template-Engine war kein Problem, solange die Ausgabe (HTML) unverändert blieb.

comwrap-website-classic-workflowStatische UI-Seite von comwrap

Das Problem bei dieser Vorgehensweise war, dass beide Projektprozesse voneinander entkoppelt waren. Änderungen im HTML-Code erforderten zwangsläufig eine erneute Implementierung ins Backend, um diesen zu aktualisieren.
Und das geriet schnell außer Kontrolle, sobald mehr als eine Zeile HTML angefasst wurde. Jede vorgenommene Anpassung musste dem Backend-Entwickler mitgeteilt und anschließend auf Vollständigkeit geprüft werden. Und egal wie gut ein Frontend-Entwickler auch ist, bei der Reimplementierung alle geänderten Tags, Klassen oder Attribute direkt zu erkennen, ist fast unmöglich. All diese kleinen Mängel summieren sich so schnell zu Problemen im Projekt, die nur schwer zu beheben sind.

"Es funktioniert gut im Frontend" oder "Ich kann den Fehler nicht reproduzieren" sind typischen Antworten, nachdem ein Fehler gemeldet wurde.


Die Herausforderung

Jedes Team hat andere Tool-Vorlieben und wir suchten nach einer Lösung, die für beide Seiten gut funktioniert. Im Frontend haben wir es vorgezogen, bei unserem bestehenden Frontend-Build-Prozess zu bleiben, der von Rosid unterstützt wird. Das Backend hingegen arbeitete bereits mit einem Komponentensystem namens Fractal und erwartete eine ähnliche Schnittstelle und Integration. Tatsächlich erfüllte Fractal bereits das, was wir suchten. Es ist eine Benutzeroberfläche, die Backend-Developern hilft, Komponenten zu erstellen und zu dokumentieren. Wir haben uns sehr bemüht, das System in unseren Build-Prozess zu integrieren, mussten letztlich aber akzeptieren, dass Rosid und Fractal nicht gut miteinander harmonieren.

fractal-screenshotUI von Fractal

Das Konzept von Komponenten

atomic-design-components
Atomic Design erklärt von Brad Frost (© Brad Frost)

Fractal hat uns gezeigt, wie die Lösung aussehen könnte. Es zwingt den Frontend-Entwickler, kleine, wiederverwendbare Komponenten zu schreiben. Das Backend verwendet dann die gleichen Komponenten und rendert sie mit echten Daten anstelle der im Frontend verwendeten Dummy-Daten. Die Komponenten können später auf vielfältige Weise zusammengebaut und genutzt werden – anegfangen von größeren Komponenten bis hin zu ganzen Seiten. Dieses Konzept ist nicht an Fractal oder ein UI im Allgemeinen gebunden, aber das Interface hilft dabei, diese Komponenten visuell zusammenzustellen, in der Vorschau anzuzeigen und zu dokumentieren. Brad Frost nennt dieses Konzept "Atomic Design". Ich empfehle das Buch, das er geschrieben hat, um mehr über robuste Designsysteme zu erfahren.

Die Lösung

Unsere Recherche und das Konzept von Fractal haben ergeben, dass wir eigentlich nach zwei Dingen suchen:

  1. Komponenten:
    Eine Möglichkeit, das gleiche HTML zwischen Frontend und Backend zu teilen. Dies erfordert eine beidseitig arbeitende Template-Engine.
  2. UI:
    Eine Möglichkeit, Komponenten zu visualisieren. Großartig für das ganze Team, denn es erleichtert die Kommunikation, wenn man zeigen kann, wovon man spricht.

Wir haben uns für Twig als Template-Engine entschieden, da die meisten Entwickler bereits damit vertraut waren.
Ein passendes UI zu finden war deutlich schwieriger. Letztendlich haben wir keine passende Lösung gefunden und eigenes System entwickelt. Nach zwei erfolgreichen Projekten können wir mit Sicherheit sagen, dass dies der richtige Schritt war.

Malvid

malvid-screenshot
Benutzeroberfläche von Malvid

Gestatten: Malvid, unsere eigene UI-Lösung.
Ein Node.js-Modul mit modernen Technologien, das sich auf Komponenten konzentriert und mit React blitzschnell gerendert wird. Wir haben alles genommen, was an Fractal für uns so großartig ist und versucht, es noch besser zu machen. Ein statischer Site-Compiler, der aus einer vorgegebenen Ordnerstruktur von Komponenten eine Web-App erzeugt.

Malvid zeigt alle relevanten Informationen auf einen Blick: Die Komponenten auf der linken Seite, oben eine Vorschau und die Vorlage, Daten und Notizen der ausgewählten Komponente auf unten rechts.

Fazit

Einen Workflow zu ändern ist nichts, was über Nacht passiert. Es erfordert viel Input von Ihren Teams, Recherchearbeit und Brainstorming. Aber verlieren Sie sich nicht in Details! Sie werden nie wissen, ob es funktioniert, bevor Sie es ausprobieren, und Sie können nicht alles auf einmal lösen. Ihr neuer Workflow kann bestehende Probleme lösen, führt aber zu neuen Herausforderungen.

Die gemeinsame Nutzung von Komponenten zwischen Frontend und Backend war für uns der richtige Schritt. Egal ob Fractal, Pattern Lab oder Malvid - versuchen Sie einen Weg zu finden, der für Ihr Unternehmen funktioniert. Der Wechsel könnte sich durchaus lohnen.

Wenn Sie Malvid live erleben wollen, können Sie dies gerne auf Malvid.io tun. In der Live-Demo werden alle Komponenten der Malvid-Website direkt im UI dargestellt. Viel Spaß beim Testen.