Components

Markdown

Flow unterstützt das Verschachteln von Components, um deine UI aufzubauen. Dies ist eine kurze Dokumentation darüber, warum wir uns dafür entschieden haben.

Die folgenden Codebeispiele werden in der Erklärung referenziert.

vs.

Logik

Components-Libraries basieren in der Regel darauf, Components zu verschachteln, um größere Components zu bauen. Das ist ein weit verbreitetes und effektives Pattern, das außerdem leicht verständlich ist. Genau deshalb unterstützen wir dieses Modell auch in Flow. Wenn man zum Beispiel ein CounterBadge innerhalb eines Buttons platziert, wird dieses automatisch oben rechts positioniert – so, wie man es erwarten würde.

Lesbarkeit

Wir haben unsere Frontend-Entwickler gefragt, was am Ende besser lesbar ist:

  1. Unterkomponenten über Props zu übergeben, wie das Icon im Beispiel
  2. Das Icon als Child in die Component zu legen.

Wir haben uns für Variante 2 entschieden, da sie besonders bei mehreren Unterkomponenten besser lesbar ist.

Wiederverwendbarkeit

Entwickler bauen häufig eigene Components, um sie wiederzuverwenden oder um die Implementierung aufzuteilen. Wenn es zum Beispiel bereits eine UnreadNotificationsCounter-Component gibt, die den Zähler aus der API lädt und in einem CounterBadge darstellt, kann diese einfach als Child im Button verwendet werden.

Suspense- / ErrorBoundaries

Nur mit dem „Components-Ansatz“ ist es möglich, Child-Components in Loading- oder ErrorBoundaries zu kapseln.

Aufgeblähtes Props-Interface

Wenn Components anfangen, Features anderer Components nativ zu unterstützen, wird ihr Props-Interface schnell aufgebläht. Beim Beispiel counterBadge={7} könnte man denken: „Hey, das ist doch nur ein Prop mehr und leicht verständlich!“ Aber was ist, wenn CounterBadge mehr Eigenschaften als nur count unterstützt? Jede unterstützte Eigenschaft müsste dann als counter[CounterProp] im Button (und möglicherweise weiteren Parent-Components) vorhanden sein.

Aufgeblähte Gesamtbibliothek vs. All-Mighty-Components

Wenn Flow für jeden Anwendungsfall spezielle Components anbieten würde, müsste es z. B. einen IconButton, einen CounterBadgeButton und streng genommen sogar einen IconCounterBadgeButton geben. Das würde schnell zu sehr vielen Components führen.

Und was wäre, wenn man stattdessen alles direkt im Button unterstützt? Das führt meist zu sehr großen „All-Mighty-Components“ ohne klaren Scope und mit überladener Implementierung.

Children in Unterkomponenten

Nur mit dem „Components-Ansatz“ ist es möglich, Children auch in Unterkomponenten zu verwenden.

Baue deine eigenen Components

Wenn du bestimmte Kombinationen von Components häufig in deiner UI verwendest, kannst du dir einfach eigene Components mit genau den Props bauen, die du benötigst.

Auf dieser Seite