Angular @ WPS Teil 2: Komponenten überall gut aussehen lassen

Angular @ WPS Teil 2: Komponenten überall gut aussehen lassen

WPS loves Angular visual

Das ist Teil 2 unserer Reihe Entwicklung von Reale-Welt-Anwendungen ohne Orientierungsverlust

von Richard Voß @richard_voss

Seit (vor-)letztem Jahr entwicklen wir bei WPS immer öfter Anwendungen für unsere Kunden mit Hilfe von Angular 4, 5, 6 und auch 7. Angular ist ein populäres Framework (es wird auch als Plattform bezeichnet) zur Entwicklung von web-basierten Frond-Ends mit Typescript, HTML und CSS. Es ist Open Source Software und wird hauptsächlich durch Google vorangetrieben.

Das Framework macht es wesentlich einfacher, komplexe GUIs zu strukturieren, fördert die Wiederverwendung von Komponenten und – am wertvollsten – erlaubt es tatsächlich, testgetriebene Front-End-Entwicklung zu betreiben, die Spaß macht.

Trotz all dieser Großartigkeit des Frameworks bleiben genug Fehler übrig, die man machen kann. Wir haben einige erfolgreiche Muster aber auch Fallstricke gefunden und gesammelt.

Dieser Artikel gibt einen weiteren Einblick in unsere „Angular Pattern Library“. Wir hatten angefangen mit dem generischen Hinweis: 👍 Factor Out Components, aber wir haben da noch nicht darüber gesprochen, was eigentlich mit dem CSS passiert…

👍 Manage Component Layout Boundaries

Die Schnittstelle einer Komponente sind nicht nur inputs, outputs und services.

Zu Beginn haben wir den Kopfschmerz unterschätzt, der entsteht wenn man eine Komponente nochmal verwendet, die einmal darauf optimiert wurde an einem ganz bestimmten Ort “gut” auszusehen. An ihrem neuen Einsatzort aber verursacht sie kollabierende Layouts, unschöne Abstände, störende Linien…

Der Grund ist dass das “Layout-Verhalten” ist ein ganz klarer Teil der Schnittstelle einer Komponente. Leider gibt es keinen definierten Standard-Mechanismus, wie man diesen Teil der Schnittstelle offensichtlich macht.

Wenn man eine bestehende Komponente verwendet, fragt man sich oft solche Dinge wie:

  • Ich habe ein schönes 12-spaltiges bootstrap-Grid, kann ich diese Komponente im sinn einer “Spalte” verwenden?
  • Kann ich die Komponente einfachen in den fließenden Text einfügen (ohne dass die Zeilenhöhe explodiert…)?
  • Warum verwendet diese Komponente nicht den vorhandenen Platz in meinem flex-Container?

Unsere Empfehlung, wie man diesen Teil der Schnittstelle offensichtlich macht

Drei einfache “Regeln” finden wir hilfreich:

  1. Definiere das “Layout-Verhalten” der Komponente, verlasse dich nicht auf den Kontext, in dem die Komponente zufällig gerade entsteht. Das bedeutet meistens einfach ein paar Minuten aktiv Nachdenken 😀
  2. Dokumentiere dieses Verhalten so, dass man es leicht erkennt. Ein Kommentar in der zugehörigen CSS– or SCSS-Datei bietet sich an, denn dort wird jemand danach suchen. Eine gute Idee für Teams sind Namenskonventionen.
  3. Limitiere die Anzahl der Muster in der Anwendung. Es sollte nicht notwendig sein, für jede Komponente wieder neu nachzudenken. (Mustersprachen, da war doch was.) Ein paar Standardmuster im Team zu etablieren hilft enorm, hier ein paar Vorschläge:
    • TileComponent für ein Block-Element mit fixer (oder fast fixer) Größe (und optisch deutlichen Rändern)
    • ContainerComponent für Komponenten die in die Breite den vollen Platz nutzen und beliebig nach unten wachsen
    • BarComponent wie ein Container, dessen Inhalt aber kurz ist un in der Regel nur einen Streifen bildet (Toolbars z.B.)
    • SymbolComponent für Text oder Icons, die man einfach überall platzieren kann
    • ExpanseComponent breitet sich komplett aus und regelt den overflow seiner Inhalte aktiv (genutzt für Wurzel-Komponenten von Anwendung)
    • … ein Team sollte selbst weitere Muster finden und Namen finden und ihre Regeln festlegen
    • Es ist übrigens wirklich hilfreich, sich bei der Frage “Flexbox oder klassisch?” ein wenig festzulegen und bei den meisten Komponenten in einem der Systeme zu bleiben. Auch das dient der Reduzierung von Komplexität.

Behandle Komponenten wie andere HTML-Elemente

Ein Problem das beim Styling und Layout oft stört ist, dass eine Angular-Komponente immer ein nicht-HTML-Element im DOM benötigt. Diese Elemente werden von Browser etwa so behandelt wie bei Verwendung der CSS-Eigenschaft display: content. Das bewirk dass der Browser das Element fast (!) ignoriert und seine Inhalte so platziert, als wären sie ohne diese Klammer im DOM. Aber spätestens bei CSS-Selektoren kann man diesen Baumknoten nicht ignorieren – er ist da und zählt in Bezug auf Vater-Kind (>) oder Geschwisterknoten-orienierte (+) Selektoren.

Wir haben herausgefunden, dass man diese Eigenschaft auf einfach aktiv gut finden kann, indem man dieses Element im DOM einfach für vollwertig erklärt und ihm einfach eigenes Layout-Verhalten schenkt. Das erreicht man durch den Pseudo-CSS-Selektor :host, den das Framework anbietet:

:host {
  display: block;
}

Diese Zeilen erfüllen bereits die oben genannten “Regeln” 1 und 2 und werden dein Entwicklerleben vereinfachen. Im Ergebnis kann man meistens darauf verzichten, in einer Komponente das ganze Template mit einem großen <div> einzurahmen (was extrem häufig zu finden ist…), denn so wird das Komponenten-Element effektiv selbst zum<div>.

Genau so kann man mit display: inline vollwertige Angular-Komponenten bauen, die visuell so klein und subtil sind wie ein einfacher Buchstabe in fließendem Text.

und weiter?

Sauber isolierte Komponenten lassen sich sehr gut testen – im nächsten Artikel lautet die Devise daher: 👍 Mock Components.

2019-01-15T10:41:47+01:0014. Januar 2019|