Symfony UX im Kontext von ModuleStudio

in  Basics , , , , ,

Symfony UX im Kontext von ModuleStudio

Stimulus und Symfony UX

Ein JavaScript-Ökosystem für Symfony wurde bereits Ende 2020 gestartet. Vereinfacht ausgedrückt wurde Symfony Flex erweitert, um auch JavaScript-Anteile in einem Bundle leicht konfigurieren und einrichten zu können. Dazu wird eine Integration mit Stimulus verwendet. Diese Struktur führt zu einer zunehmenden Standardisierung und Aufteilung in wiederverwendbare UX-Komponenten.

Seitdem ist eine Menge passiert: nach Webpack Encore 1.0 und Stimulus Bridge 2.0 kam Symfony UX Turbo, das auf der Basis von Turbo das Schreiben von JavaScript in vielen Fällen überflüssig macht. Anschließend gab es noch einen weiteren Versionssprung, so dass wir aktuell bei Symfony UX 2.0 und Stimulus 3 stehen.

Vor etwa einem Monat wurde dann eine eigene Website gelauncht, wie sich dieser Ankündigung entnehmen lässt. Auf ux.symfony.com werden die verfügbaren Komponenten vorgestellt und können direkt ausprobiert werden.

Was heißt das für ModuleStudio?

Die UX-Komponenten passen hervorragend zur Strategie von Zikula 4. Bisher musste die Zikula-Plattform als eierlegende Wollmilchsau fungieren und alle möglichen Frontend-bezogenen Funktionen vorhalten, die die Module eventuell nutzen wollten.

Zukünftig können bestimmte Funktionen, die im Rahmen der Modellierung eines Bundles gewünscht und aktiviert werden, über eine entsprechenden Dependency dazu geladen werden.

Dies ist zum Beispiel sehr naheliegend für AutoComplete-Felder, Datei-Uploads, das Zuschneiden von Bildern, automatische Form Validierung oder abhängige Formularfelder.

Falls man also in ModuleStudio ein AutoCompletion modelliert, wird das generierte Bundle eben eine Abhängigkeit auf symfony/ux-autocomplete beinhalten. Falls es Upload-Felder gibt, wird symfony/ux-dropzone eingebunden, und bei Bildern vielleicht noch symfony/ux-cropperjs. Alles in allem können solche Anbelange dann wiederum aus dem Zikula Core entfallen.