Die neue Shopware 6 Storefront und was du alles darüber wissen solltest
There is also an english version of this post. Please check out:
Mit Shopware 6 wurde viel umgedacht, viel Raum für Neues geschaffen. Weil Shopware nicht nur eine reine Software für Anwender ist, sondern ebenso als eine Art Framework für Entwickler fungiert, sind auch die Anforderungen und Bedürfnisse aus der Developer Community ein wichtiges Thema bei der Weiterentwicklung.
Während sich der Löwenanteil wie so oft im Software-Business unter der Oberfläche befindet und sich zumeist den Blicken der Mehrheit entzieht, dreht sich im E-Commerce vieles aber auch um Optik, Look & Feel, Performance und Co. — Grund genug also, mit Shopware 6 auch im Frontend neue Wege zu gehen!
Shopware 6 setzt vollständig auf dem bewährten PHP-Standard-Framework Symfony auf. Nur verständlich also, dass damit die ebenfalls aus dem Hause SensioLabs stammende Template-Engine Twig Einzug gehalten hat und damit das bisher verwendete Smarty ablöst. Aber die Standardisierung hört hier noch lange nicht auf — im Gegenteil! Bootstrap CSS Framework statt Eigenentwicklung, Sass statt LESS, objektorientiertes JavaScript (ES6), Webpack… die Liste ist lang und ebenso die daraus resultierenden Vorteile und Änderungen.
Welche Neuerungen dich konkret erwarten und worauf es in der Shopware 6 Storefront ankommt, das will ich dir im weiteren Verlauf dieses Beitrags gerne aufzeigen.
In Einzelteile zerlegt — die Shopware 6 Storefront
Um das große Ganze verstehen zu können, muss man oft zunächst die einzelnen Bestandteile betrachten und wie diese schlussendlich auch zusammenspielen. Aus diesem Grund beleuchten wir nachfolgend gemeinsam die einzelnen Komponenten der neuen Storefront, beginnend mit den drei elementaren Schichten einer webbasierten Applikation und den verwendeten neuen Tools und Standards. Damit für dich nachvollziehbarer wird, weshalb manche Dinge plötzlich anders als bisher gewohnt laufen, will ich versuchen Brücken zu den verschiedenen Pendants aus Shopware 5 zu schlagen.
Strukturschicht (Structure & Content)
Das Fundament eines Web-Frontends bildet die Strukturschicht — in ihrer einfachsten Ausprägungsform bestehend aus statischem HTML Markup, aufgeteilt in logische oder inhaltsbezogene Abschnitte. Für die Realisierung höherer, technischer Anforderungen existieren sogenannte Template-Engines, die das Rendern von HTML Markup mit Hilfe von Vorlagen (Templates) übernehmen. Nichts Neues für jeden, der bereits mit einer früheren Version von Shopware gearbeitet hat.
Neu ist jedoch, dass fortan Twig als Template-Engine zum Einsatz kommt, während man bis einschließlich Shopware 5 noch auf Smarty setzte. Ebenfalls aus den Händen der Symfony-Macher allein schon aus Gründen der Integration und der Interoperabilität im Symfony-Kosmos eine rein logische Schlussfolgerung. Ohne weiter großartig auf Details eingehen zu wollen, gilt Twig als eines der schnellsten, sichersten und flexibelsten unter den etablierten, PHP-basierten Template-Engines auf dem Markt.
Wie so oft gilt auch hier: Neue (oder besser “andere”) Technologien bringen eine gewisse Einstiegshürde mit sich. Beispielsweise die Syntax — diese unterscheidet sich bei Twig natürlich von der altbekannten Smarty Schreibweise. Nützliche Informationen zum Umgang mit Twig, dem Funktionsumfang, Erweiterbarkeit und Coding Standards findest du in der offiziellen Dokumentation.
Die wichtigsten Aspekte im Umgang mit Twig in der Storefront
Debugging — Ein simpler VarDump auf ein Objekt in der View konnte Smarty gehörig in die Knie zwingen. Bei Twig sieht das gänzlich anders aus — zum Glück! Dank der integrierten VarDumper-Komponente und dem DebugBundle von Symfony können fortan alle Variablen in der Storefront sorgenfrei ausgegeben werden:
// Ausgabe aller in der aktuellen View verfügbaren Variablen
{{ dump() }}// Ausgabe einer oder mehrerer spezifischer Variablen
{{ dump(page.detail[, ...]) }}
Und dabei steht zusätzlich die Übersichtlichkeit der Debug-Ausgabe im Vordergrund. Dank der visuellen Aufbereitung gehören unübersichtliche “print_r” Ausgaben somit der Vergangenheit an:
Textbausteine — Ebenfalls anders gestaltet sich das Thema Textbausteine. Während im Smarty Kontext noch mit eigens dafür entwickelter Snippet-Funktion gearbeitet und jeder Textbaustein durch eine Kombination aus Name und Namespace identifiziert wurde, läuft es in Twig etwas anders:
// Bisher in Smarty
{s name='OrderColumnId' namespace='frontend/account/orders'}{/s}// Twig
{{ 'account.orderItemNumber'|trans }}
Über den “trans” Filter, welchen Symfony und Twig standardmäßig bereitstellen, können Textbausteine an beliebiger Stelle im Template gesetzt und aus der zugrundeliegenden Datenquelle (z.b. messages.de.yaml für deutsche Textbausteine, messages.en.yaml für englische Übersetzungen) konsumiert werden.
Extends & Include — Technisch gut gelöst ist in Twig das Thema Erweiterbarkeit. Die Möglichkeit der Erweiterung des Funktionsumfangs durch eigene Tags, Filter, Functions und Tests über einen rein objektorientierten Ansatz und die Unit-Testbarkeit solcher, stellt besonders für Projekte im Enterprise-Sektor ein reizvolles Instrument zur Implementierung individueller Bedürfnisse dar.
Und gerade diesen Instruments bedient sich auch die neue Storefront. Weil Plugins sowie individuelle Themes eine mehrstufige Vererbungshierarchie bilden, die Twig im Standard nicht unterstützt, wurden zwei Shopware-spezifische TokenParser implementiert, die mittels der Tags “sw_include” sowie “sw_extends” in der Storefront Anwendung finden. Diese beiden sind anstelle der eigentlich im Standard bestehenden Tags “include” und “extends” zu verwenden und gewährleisten so, dass ein Überschreiben von Template Blöcken, etwa durch Plugins, möglich ist.
Möchte man also beispielsweise eine View von einer anderen erben lassen, ist darauf zu achten, dass “sw_extends” verwendet wird:
// @Storefront/page/account/logout.html.twig
{% sw_extends '@Storefront/page/account/_page.html.twig' %}Gleiches gilt für den Fall, dass man in einer View eine Template-Datei einbinden möchte. Hier ist “sw_include” zu verwenden:
// @Storefront/base.html.twig
{% sw_include '@Storefront/layout/meta.html.twig' %}Icons & Thumbnails— Natürlich bietet es sich an, kleine Helferlein zu implementieren, die das Daily Business für Template Developer erleichtern sollen. Aus diesem Grunde ist “sw_icon” entstanden, welches das bequeme Konfigurieren und Laden von SVG-Icons ermöglicht:
// Exemplarische Verwendung von "sw_icon" im Template
{% sw_icon 'marketing' style { 'color': 'success', 'size': 'fluid', 'pack': 'default' } %}Ebenso komfortabel ist die Verwendung von “sw_thumbnails”, das anhand der übergebenen Parameter einen <img> Tag mit korrekt konfigurierten “srcset”- und “sizes”-Attributen rendert:
// Exemplarische Verwendung von "sw_thumbnails" im Template
{% sw_thumbnails 'confirm-shipping-current-image-thumbnails' with {
media: context.shippingMethod.media,
sizes: {
'default': '100px'
},
attributes: {
'class': 'confirm-shipping-method-image',
'alt': context.shippingMethod.media.translated.alt,
'title': context.shippingMethod.media.translated.title
}
} %}Die Organisation der Twig Files in der Storefront und deren Aufbau hat sich im Vergleich zu Shopware 5 natürlich auch etwas verändert. Allerdings gibt es hier keine großartigen, technischen Finessen auf die gesondert eingegangen werden müsste. So viel daher für den Moment zur Strukturschicht.
Präsentationsschicht (Presentation)
In der heutigen Zeit ist ein Onlineshop ohne modern anmutendes, benutzerzentrisches Look & Feel unvorstellbar geworden. Die sogenannte Präsentationsschicht erlaubt es uns, den Look einer Applikation mittels CSS an das HTML Markup zu binden.
Dabei gilt — je allgemeiner die CSS Definitionen gehalten sind, desto losgelöster sind diese vom konkreten Markup. Je spezifischer, desto schneller können Änderungen im Markup zu ungewollten, sichtbaren Side-Effects führen.
Weil CSS heutzutage viel mehr ist als nur Styles auf Selektoren zu setzen, gibt es seit etlichen Jahren diverse, sogenannte CSS Preprozessoren. Mithilfe dieser lassen sich syntaktische Regeln und Sprachkonstrukte verwenden, um effizienter CSS zu erzeugen. Genauer gesagt wird durch eine eigene Stylesheet-Sprache der eingeschränkte Funktionsumfang von CSS durch Variablen, Funktionen, Mixins und Co. erweitert. Weil der Browser allerdings nur CSS verarbeiten kann, werden die erzeugten Files mittels des Preprozessors zu einem vorangehenden Zeitpunkt in valides CSS kompiliert. Dieses Kompilat wird schließlich im HTML Markup geladen und vom Browser interpretiert.
Der Preprozessor Umstieg: von LESS zu Sass
Wer schon mit Shopware 5 gearbeitet hat, der kennt bereits die Stylesheet-Sprache LESS. Bei Shopware 6 ist nun ein konsequenter Umstieg auf Sass erfolgt. Beim Vergleich von Frameworks, Sprachen oder Tools steckt der Teufel wie so oft im Detail — die bekanntesten CSS Preprozessoren (das sind Sass, LESS, Stylus, PostCSS) unterscheiden sich funktional betrachtet circa 20% voneinander, die restlichen 80% sind deckungsgleich. Zu behaupten Sass sei besser, schneller, toller als LESS wäre daher eine rein subjektive Aussage.
Ein Kriterium das für den Umstieg auf Sass spricht und zudem nicht so leicht von der Hand zu weisen ist, ist jedoch das Thema der Verbreitung. Wie nachfolgendes Diagramm zeigt, wurde bei einer Umfrage die Verteilung diverser CSS Preprozessoren ermittelt. Dabei hebt sich Sass ganz klar von der Konkurrenz ab:
Ein weiteres Argument für den Umstieg von LESS auf Sass ist das Thema “CSS Framework”. Nach ausführlicher Evaluation fiel für Shopware 6 die Entscheidung hierbei auf das etablierte Bootstrap Frontend-CSS-Framework, dessen Marktanteil sich ebenso deutlich von bestehenden Alternativen absetzt. Mit Version 4 des Frameworks sind Source-Files fortan als Sass-Files (genauer gesagt in der Syntax-Ausprägung SCSS für “Sassy CSS”, also mit der Dateiendung *.scss) geschrieben. Somit liegt auch aus diesem Aspekt heraus der Umstieg zu Sass förmlich auf der Hand.
Bootstrap 4: Source-Files nutzen und profitieren
Wie eben erwähnt, liegen die Source-Files von Bootstrap als Sass-Files vor. Es ist somit möglich, die darin definierten Variablen, Mixins und Functions für eigene Zwecke zu nutzen. Welche dies sind und wie sie man sie verwendet, kann der offiziellen Dokumentation entnommen werden.
Nun, nichts wirklich Neues… schließlich konnten in Shopware 5 bereits definierte LESS Konstrukte wiederverwendet werden. Was also ist hier nun als konkreter Benefit für die neue Storefront zu nennen?
Dokumentation eines gewissermaßen Standards — Anstelle von Eigenimplementierungen wird dank der Verwendung von Bootstrap auf einen in gewisser Weise bestehenden Standard gesetzt. Functions, Mixins und Co. sind so allein durch die Community bereits tausendfach getestet, werden regelmäßig verbessert sowie erweitert und liegen in entsprechender Form ausführlich dokumentiert vor. Ein Umstand, der bei Anpassungen in der Storefront ein rasches, zielgetriebenes Vorankommen ermöglicht.
Reduktion auf das Wesentliche — Insbesondere weil viele Themen und Probleme (z.B. Grid-System, diverse Komponenten, Browser-spezifische Eigenheiten, etc.) dank des Bootstrap Frameworks bereits als gelöst anzusehen sind, liegt der Fokus bei der Implementierung der neuen Storefront auf dem wirklich Wesentlichen. Durch die Verwendung der Source-Files und ferner explizit jener Bestandteile, die in der Storefront auch tatsächlich benötigt werden, lässt sich außerdem das Kompilat, d.h. das am Ende erzeugte CSS-File, ebenfalls auf das Wesentliche reduzieren. Dies wiederum dient der Performance und verbessert die Ladezeit der Storefront.
SCSS in trockenen Tüchern — Ein bekanntes Paradigma des Software Engineerings ist DRY (Don’t repeat yourself). Dieses besagt, dass redundanter Code vermieden oder zumindest reduziert werden sollte. Dank Variablen, Mixins und Functions sowie der Möglichkeit, von bestehenden Selektoren zu erben (mittels @extend Anweisung), können Definitionen und Konstrukte bequem wiederverwendet werden. Weil Bootstrap hier ein zahlreiches Portfolio mitbringt, können schnell und unkompliziert neue Buttons, Labels, Notifications, Grids und Co. erzeugt werden. Ein großer Benefit, besonders um schnell den groben Aufbau einer View zu implementieren. Aber selbstverständlich auch, wenn es um die Feinheiten geht.
Erweiterbarkeit — Aufgrund der großen Verbreitung von Bootstrap, auch in anderen Webapplikationen und -systemen, können bereits heute zahlreiche 3rd-Party Module konsumiert und für die eigenen Zwecke in der Storefront eingesetzt werden. Gewisse, notwendige Anpassungen lassen sich selbstverständlich nie gänzlich vermeiden. Dafür ist das Thema Frontend einfach oft zu spezifisch bzw. vom jeweiligen Projektscope abhängig. Um jedoch schnelle Erfolge oder gar technische Durchstiche zu erzielen, ist dies ein maßgeblicher Benefit der Verwendung des Bootstrap 4 CSS-Framework in der neuen Shopware 6 Storefront.
Corporate Identity — Wer sich bereits mit Bootstrap befasst hat, der weiß, dass dort zahlreiche Variablen zur individuellen Konfiguration einladen. So kann man an einem zentralen Ort die Stellschrauben betätigen um damit das gesamte Look&Feel auf die eigenen Bedürfnisse anzupassen. Dank der mit “!default” Keyword versehenen Variablen innerhalb der Bootstrap Source-Files eine ziemlich praktische Sache. Besonders auch im Hinblick auf das Thema “Skins” im Kontext der neuen Storefront. Das mitgelieferte “Shopware Skin”, eine Ansammlung von SCSS-Files, liegt sozusagen als Schicht über den Bootstrap Stylesheet Definitionen und schmückt das Default-Theme der neuen Storefront somit im CI von Shopware. Ist hierfür in einem eigenen Projekt kein Bedarf, kann dieses “Skin” ohne große Mühen entfernt bzw. durch ein eigenes ersetzt werden.
Organisation ist die halbe Miete
Um auch die in einem Softwareprojekt omnipräsente Frage nach der Organisationsstruktur von Ordnern und Dateien geklärt zu haben, orientiert sich die neue Storefront grundsätzlich am sogenannten 7–1 Pattern, einem Organisationsmuster das sich im Sass Umfeld über die Zeit etabliert hat. Aufgeteilt in sieben getrennte Bereiche (bzw. Ordner) sind so diverse Verantwortlichkeiten logisch getrennt.
Nachfolgende, beispielhafte Darstellung der Organisationsstruktur von SCSS Files soll diese Trennung von Verantwortungsbereichen verdeutlichen:
|– abstract/ # Helper die selbst keinen Output erzeugen
| |– _variables.scss # Sass Variablen
| |– _functions.scss # Sass Funktionen
| |– _mixins.scss # Sass Mixins
| |– _placeholders.scss # Sass Platzhalter
| … # Etc.
|
|– base/ # Boilerplate des Themes
| |– _base.scss # Basis Styles
| |– _reboot.scss # Reset/normalize
| … # Etc.
|
|– component/ # Widgets/Module/Komponenten Styles
| |– _alert.scss # Alerts
| |– _card.scss # Card
| |– _forms.scss # Formulare
| |– _icon.scss # Icons
| … # Etc.
|
|– layout/ # Globale Wireframe Styles
| |– _account-menu.scss # Account Menü
| |– _container.scss # Container
| |– _header.scss # Header
| |– _footer.scss # Footer
| … # Etc.
|
|– page/ # Seiten spezifische Stylesheets
| |– account/ # Account spezifische Files
| | |- _login.scss # Login spezifische Styles
| | |- _profile.scss # Profil spezifische Styles
| | |– … # Etc.
| |– checkout/ # Checkout spezifische Files
| | |– … # Etc.
| … # Etc.
|
|– skin/ # Skins
| |– shopware/ # Shopware Skin Files
| | |– … # Etc.
| … # Etc.
|
|– vendor/ # Einbinden und Konfigurieren von Vendoren
| |– _bootstrap.scss # Bootstrap
| |– _tiny-slider.scss # Tiny Slider
| … # Etc.
|
|– base.scss # Haupt-Datei mit Import aller Partials
|– variables.scss # Import aller VariablenDie klare Aufteilung ermöglicht dabei nicht nur ein übersichtlicheres Organisieren von Styles, vielmehr weist sie den Entwickler zugleich darauf hin, Anpassungen bewusster vorzunehmen sowie neue Dateien konsequenter dem geeigneten Themengebiet zuzuordnen.
Tipp
Eine möglichst lose Kopplung von Komponenten zu anderen Files ermöglicht es, diese ohne größere Mühen in andere Themes oder gar Projekte zu migrieren.
Verhaltensschicht (Behaviour)
Zu guter Letzt wird über die Struktur- und die Präsentationsschicht schließlich die Verhaltensschicht gestülpt. Auf dieser Ebene ist all das angesiedelt, das dem Anwender eine interaktive Bedienung ermöglicht. Im Falle einer Webapplikation übernimmt dies primär die Skriptsprache JavaScript, kurz JS.
Weil der JavaScript zugrundeliegende, standardisierte Sprachkern ECMAScript es seit Version 6 erlaubt, objektorientierten Code in einer Syntax ähnlich anderer klassenbasierter Programmiersprachen zu erzeugen, hat JS in den letzten Jahren deutlich das Interesse der Programmierwelt für sich geweckt. Und weil mit der OOP-ähnlichen Schreibweise analog dazu ebenfalls Themen aus der Softwarearchitektur Einzug halten (Clean Code Prinzipien, Vererbung, Komposition, Separation of Concerns, etc.), hat sich auch das Qualitätsbewusstsein in diesem Bereich deutlich zum Positiven gewandelt.
Für die Entwicklung der neuen Storefront stand schnell fest, dass auf ES6 und somit klassenbasierte Syntax gesetzt wird. So sind schließlich auch diverse Tools — genauer gesagt Helferklassen — entstanden, die unterschiedlichste Aufgaben in der neuen Storefront übernehmen. Die wichtigsten möchte ich nachfolgend kurz aufzeigen:
ViewportDetection — Während in Shopware 5 noch der “StateManager” für allerlei Dinge verantwortlich war, gibt es in der Shopware 6 Storefront nun eine dedizierte ViewportDetection-Klasse. Im Zusammenspiel mit den von Bootstrap bereitgestellten CSS-Viewports bietet diese Klasse die Möglichkeit, über eigens dafür erzeugte Events auf das Wechseln des Viewports zu reagieren:
document.addEventListener('Viewport/hasChanged', () => {
console.log('Viewport has changed');
});Zusätzlich hierzu stehen separate Events je Viewport zur Verfügung, sowie Methoden um den aktuellen Viewport zurück zu erhalten. Wichtig zu erwähnen ist, dass die Klasse sich ausschließlich mit diesem Thema befasst (Separation of Concerns, d.h. Trennung von Verantwortlichkeiten).
DeviceDetection — Die DeviceDetection Klasse wiederum hat zur Aufgabe mit kleinen, statischen Funktionen durch einfache Anwendung bool’sche Aussagen über das verwendete Device zu treffen. Möchte man beispielsweise in Erfahrung bringen, ob es sich beim aktuellen Gerät um ein TouchDevice handelt, ist dies folgendermaßen möglich:
import DeviceDetection from '../device-detection.helper';...
if(DeviceDetection.isTouchDevice()) {
console.log('This device is of type touch device');
}
DomAccess — Schnell und typsicher prüfen ob ein Node Element ein Attribut besitzt? Dies ist unter anderem Aufgabe der DomAccess Helferklasse. Die Klasse abstrahiert den Zugriff auf Node Elemente, Attribute und Data-Attribute und kümmert sich darum, dass verlässliche Ergebnisse zurück erhalten werden.
import DomAccess from '../dom-access.helper';...
if(DomAccess.hasAttribute(element, 'attribute')) {
console.log('The attribute exists');
}
Ein weiteres Beispiel verdeutlicht, welchen Komfort die Helferklasse zusätzlich bereitstellt. Will man eine Klasse implementieren, deren Ausführung nur dann erfolgen soll, wenn der korrespondierende Selektor als Bedingung im HTML Markup auffindbar ist, dann lässt sich dies exemplarisch wie folgt lösen:
import DomAccess from '../dom-access.helper';...constructor(){
try {
this.el = DomAccess.querySelector(document, '.js-modal'));
...
} catch (e) {
// do nothing
}
}
Intern wird eine Exception geworfen, wenn der angegebene Query Selector kein Ergebnis liefert. Auf diese kann dann per try/catch reagiert werden. Als dritter, optionaler Parameter ist es außerdem möglich den Strict-Mode auszuschalten, somit kommt bei Nichtauffinden eines Elements ein bool’sches FALSE zurück. Prüfungen auf “!== typeof undefined” und Co. gehören damit der Vergangenheit an. Es genügt damit immer die Prüfung auf “!== FALSE”.
HttpClient — Wer bereits JavaScript-seitig mit asynchronen Requests gearbeitet hat, der weiß worauf es ankommt. Bestehende, noch aktive Requests abbrechen bevor man einen neuen absetzt, die richtige Request Methode verwenden, Callbacks, ContentType festlegen und im Kontext mit der neuen Shopware 6 API sogar zudem Zugriffscredentials setzen. Weil all das nun hinter ein einfach zu verwendendes Interface gewandert ist, bietet die HttpClient Klasse die Grundlage für ein “easy-to-use” HTTP Request-Handling ohne großen Overhead wie nachfolgender Auszug zeigt:
import HttpClient from '../http-client.service';...this.client = new HttpClient(window.accessKey, window.contextToken);...const requestUrl = DomAccess.getAttribute(form, 'action');
const data = FormSerializeUtil.serialize(form); this.client.post(
requestUrl.toLowerCase(),
data,
this._onOffCanvasOpened.bind(this)
);
Zahlreiche weitere, kleine Helferlein sowie Features sorgen in der neuen Storefront für eine übersichtliche, moderne JS Code-Basis die es dem Entwickler ermöglicht, schnell gewünschte Ergebnisse zu erzielen und den Funktionsumfang auf seine projektspezifischen Bedürfnisse anzupassen.
Webpack Module Bundler
Zu guter Letzt möchte ich noch kurz auf etwas eingehen, das für die Verwendung der genannten neuen Technologien aus verschiedenen Aspekten heraus essentiell ist. Während bei Shopware 5 noch Grunt als TaskRunner im Einsatz war um beispielsweise CSS und JS Code zu kompilieren, kommt Shopware 6 nun mit dem Module Builder Webpack im Schlepptau. Internationale Größen wie Airbnb, Trivago, Adobe, Slack und Co. setzen schon seit geraumer Zeit auf Webpack, welches sich mittlerweile langsam aber sicher zu einer “State of the art”-Technologie entwickelt hat.
Dank Webpack ist es uns beispielsweise möglich, den in ECMAScript 6 geschriebenen JS-Code mittels Babel Compiler in Cross Browser kompatibles JavaScript umzuwandeln. Ferner kümmert sich Webpack dank zahlreicher Plugins und Loader um das Kompilieren von SCSS zu CSS, das Erzeugen browser-spezifischer CSS Anweisungen (Autoprefixing), die Minimierung der Kompilate, etc.
Dies eröffnet zudem weitere Möglichkeiten, die vor allem im Enterprise Sektor interessant sind. Mittels Webpack lassen sich, nur um einen kleinen Ausblick in die Zukunft zu wagen, sogenannte Entrypoints realisieren. Kleine, geschnürte Pakete sozusagen, die je View nur den Code beinhalten, der dort auch tatsächlich benötigt wird. Dies reduziert ungewollte Side-Effects bei Anpassungen, die Dateigrößen von CSS und JS Kompilaten sowie die Last für den Client, sprich den Browser da nur das JavaScript läuft, das im Kontext der jeweiligen View zum Einsatz kommt. Natürlich ist dies nicht einfach so ohne weiteres Zutun möglich. Wie man das allerdings am Besten anstellt und welche Aufwände hierfür anfallen, sollte Thema eines anderen Beitrags sein.
Dass man im Entwicklungsstadium eines Projekts andere Anforderungen an die Systemumgebung hat als dies im Produktionsmodus der Fall ist, kann auch im Bereich der Storefront dank der flexiblen Webpack Konfiguration berücksichtigt werden. Die hierfür zur Verfügung stehenden Konfigurationsdateien lauten:
- webpack.base.config.js — Beinhaltet die Grundkonfiguration, die für alle verfügbaren Environments gelten
- webpack.dev.config.js — Hier finden sich Konfigurationen, die für Webpack im Modus “dev” oder “watch” gelten
- webpack.hot.config.js — Konfigurationen, die explizit für den eingebauten Webpack HMR Modus gelten
- webpack.prod.config.js — Speziell für den Produktionsmodus angepasste Konfiguration
Je eingestellter Environment (dev|watch|hot|prod) werden die Basiskonfiguration und die spezifische Konfiguration zusammengemerged. Es entsteht daraus die finale Konfiguration von Webpack mittels welcher schließlich JS und CSS Files erzeugt, mitsamt notwendiger Ressourcen (Fonts, Images, etc.) in den Build-Folder gezogen und bereitgestellt werden.
Eine ausführliche Dokumentation steht auf der offiziellen Website von Webpack zur Verfügung und kann für eigene Anpassungen zu Rate gezogen werden.
Fazit
Viel ist geschehen seit Shopware 5, einiges hat sich grundlegend verändert und es wurde mit der Zeit gegangen. Für mehr Qualität, mehr Abgrenzung, mehr Möglichkeiten — auch in der Storefront. Dass dieser Umstand ein gewisses Maß an Umdenken erfordert, liegt in der Natur der Sache. Doch nur so ist es möglich, Shopware 6 und die damit zu realisierenden Projekte auf ein neues Level zu bringen. Der Markt entwickelt sich weiter und mit ihm die Anforderungen. Die neue Shopware 6 Storefront gibt dir und deinem Projekt alle Möglichkeiten an die Hand um auch künftig mit der Zeit gehen zu können.
