Auf Smashing Magazine ist ein laaaaanger Artikel zum Design (oder besser: Konzeption) von Komponenten auf Websites erschienen:

„The Key To Good Component Design Is Selfishness“, Daniel Yuschick, 20.1.2023

Um es vorweg zunehmen: ich schließe mich Yuschicks Schlussfolgerung nicht an und bin da ganz bei einem Leserkommentar unter dem Artikel. Aber das Durchdeklinieren der Probleme und die daraus resultierenden Folgerungen sind anregendes Denkfutter.

Yuschick stellt prototypisch dar, was in jedem größeren Projekt passiert und was in jedem Projekt ein PITA ist: das Aufblähen von Komponenten. Dazu nimmt Yuschick zuerst einen Button (später ein Modal) in einer Grundkonfiguration, als Primary und Secondary Button mit konfigurierbaren Text, und bastelt daraus eine React-Komponente inkl. Markup.

Dann kommt die erste Eskalation: das Projekt will gerne optional ein Icon rechts vom Text haben. Okay, Komponente umgebaut.

• Nächste Iteration: es soll ein Tertiary Button eingeführt werden und Icons sollen optional links vom Text erscheinen können.
• Dritte Iteration: Einbau von Icons mit einer Farbe die von der Textfarbe abweicht.
• Vierte Iteration: Icons-only-Button, also Buttons wo der Text optional ist und die Icon-Position deswegen nicht „links“ oder „rechts“ vom Text sein kann.

Jeder Entwickler kennt dies: jede Iteration kann die grundsätzliche Ausgangssituation derart verändern, dass es nicht mehr über ein Anflanschen zusätzlicher Anforderungen getan ist, sondern ein Komplettumbau eigentlich angemessen wäre. Ein Komplettumbau bringt i.d.R. auch eine Veränderung der Konfiguration mit sich und jede Konfiguration von bereits verbauten Buttons, muss angepasst werden.

Verschiebung of Concerns

Yuschick leitet daraus die Frage nach der „Verantwortung“ einer Komponente ab.

What is the responsibility of an HTML button element exactly? Narrowing down this answer will shine light onto the issues facing the previous Button component.

The responsibilities of the native HTML button element go no further than:

• Display, without opinion, whatever content is passed into it.
• Handle native functionality and attributes such as onClick and disabled.

[…]

The onus of formatting any content within the button isn’t the responsibility of the button but of the content itself. The button shouldn’t care. The button should not share the responsibility for its content.

Yuschicks Beobachtung mündet in Fatalismus…

When the component is responsible for the content it displays, it will break down because the content will forever and always change.

… und der Schlussfolgerung: lass Content Content sein und kümmere dich nicht um ihn. In der Verantwortung einer Komponente läge nur das Aussehen (huh?), die Funktionalität (Klicks etc…) und Zustand (Position, Sichtbarkeit).

Würde Yuschicks Artikel an dieser Stelle aufhören, würde ich die Conclusio in Bausch & Bogen verdammen. Aber Yuschick geht noch einen Schritt weiter, mit dem er sein eben verkündetes Dogma dezent aufbricht. Er fängt an, über Komposition, also Zusammenbau von Komponenten zu schreiben. Ein Modal besteht z.B. nicht einfach aus „Inhalt“, sondern Subkomponenten für Header, Main und Footer. Smells like Atomic Design?

Yuschick fängt hier an argumentativ zu wackeln. Während er im Kontext der Komposition von „child components“ spricht, stellt er später die Bestandteile von Modals als „little more than a semantic container for any content“ vor und redet sie wieder klein. Die Frage ob Eingabefelder im Main-Bereich des Modals jetzt „Content“ oder Subkomponenten sind, betrachtet er leider nicht.

Verschiebung of Verantwortung

Der Leserkommentar von Rich arbeitet sich an der nicht möglichen Kapselung von Content entlang der von Yuschick vorgeschlagenen Grenze ab.

Der Schlüssel liegt in Richs Formulierung von „By removing responsibility for content” – die Verantwortung wird aus dem eigenen Verantwortungsbereich weg geschoben … aber wohin sie geschoben wird, wird von Yuschick nicht erwähnt.

Die Grenze von Yuschick bedeutet letztendlich, dass Content HTML-Markup wird (was jetzt schon zB bei Richtext der Fall ist). Und das kann eine sehr problematische Entscheidung sein.

Im Kontext von größeren Websites mit Content Management Systemen ist davon auszugehen, dass Inhalte von Redakteuren gepflegt werden. Diese Redakteure besitzen über ein sehr heterogenes Wissen von HTML. Redaktionsleitfaden mit den Beschreibungen für die Einstellungen von mehreren Dutzend unterschiedlichen Modulen werden eh schnell sehr umfangreich. Darin auch noch die Usance zum Pflegen von HTML-Markup unterzubringen, ist in den Projekten in denen ich drin bin, nicht vermittelbar. Kurz gesagt: Redakteure sind i.d.R. keine HTML-Kenner.

In Yuschicks Definition ist Content nicht mehr Content, sondern ein Brei aus Code und Content – Text mit HTML-Code angereichert, der zufällig auch noch die richtige Klasse am SPAN-Element hat, um im Button das richtige Icon anzuzeigen.

Yuschicks Folgerung löst kein Problem, sondern verschiebt das Problem in eine sehr, sehr üblen Ecke: weg vom Code, Dateien und Templates, hin zu Content, der in Datenbanken versenkt ist. Der ist damit etliche Ecken vom Entwickler weiter weg und wird bei der nächsten Content-Migration einen Haufen Ärger machen.

Fazit

Yuschicks Artikel ist der Tritt in den Hintern, sich noch einmal zu hinterfragen, wie es mit „Separation of Concerns“ im Bereich der Komponenten aussieht. Wieviel Verantwortung hat die Komponente, wieviel Verantwortung haben Subkomponenten und wieviel Verantwortung hat der Inhalt.

Der Verantwortungsbereich des Inhaltes lässt sich daraus ableiten, wer den Inhalt pflegt. In größeren Projekten werden es nicht Entwickler:innen, sondern Redakteure sein und dass reduziert automatisch den Verantwortungsbereich von „Inhalt“.

Was in den Diskussionen über Komponenten IMHO überraschend häufig ausgeblendet wird, sind Hierarchien. Auch in Designsystemen oder Komponentenbaukästen gibt es häufig nur eine einzige Ebene von Komponenten, die einen Button auf Augenhöhe mit einem Modal behandelt.

Ich halte es für eine Stärke von Atomic Design über „Atome“, „Moleküle“ und „Organismen“ den Komponenten eine Hierarchie mitzugeben. Damit ergibt sich auch eine Beschreibung der Verantwortungsbereiche z.B. einer Modal-Komponente und einer Button-Komponente, die in einem Modal steckt. Ein Button ist ein Button ist ein Button ist ein Button. Und für alles was im Modal bzgl. des Buttons darüber hinaus geht, ist das Modal zuständig (abweichende Positionierung etc…). Entweder bin ich an diesem Punkt ein störrischer alter Esel, oder es hat seine Grund, warum die Projekte damit gut laufen.