FROM CACHE - de_header

scss ist veraltet - was soll ich machen?

ChristianDE
Tourist
13 0 1

@Gabe 

Ich habe ein großes Problem mit meinem Venture Theme. Mir wird gesagt, dass scss veraltet ist. Ich kann nichts mehr verändern ohne dass dann nichts mehr funktioniert. Wie compile ich scss einfach und verständlich in css und muss ich dann was im theme.liquid danach ändern?

Seit Tagen versuche ich eine Lösung zu finden. Ich finde, dass man bei diesem Thema von Shopify extrem im Stich gelassen wird. Das Gedusel mit dem Shopify Theme Kit verstehe ich nicht und ist sehr kompliziert.

Hoffentlich gibt es eine einfache Lösung für dieses Problem. Vielen Dank.

3 ANTWORTEN 3

r8r
Shopify Expert
2555 327 940

@ChristianDE siehe Originalthread

★ Ja, man kann mich buchen; schreib mir eine Nachricht!
★ Hinterlass gerne ein Like und markiere meine Antwort gegebenenfalls als Lösung. Ich freue ich mich immer über eine Spende an die (Kinder)krebshilfe oder eine kleine Aufmerksamkeit.
Studio Mitte
Gift-o-the-Jab
Seefahrer
358 23 95

@ChristianDE @r8r 

Und diesen... Und diesen. Und diesen. Meine Kommentare dazu:

Variablen sind eine Sache.. Aber die Sass-Mixins was anderes. Das kann zu doppeltem Code führen... 

Das local compiling funktioniert gut mit anderen Dev-Workflows, aber nicht mit Shopify. Man kann eine Produktionsversion eines Themes kompilieren und hochladen (oder in diesem Fall eine scss-zu-css-Datei), aber sobald ein Kunde oder eine App eine Änderung an einer kompilierten css-Datei im Shop vornimmt, ist es unmöglich, diese Änderungen zurück in die Entwicklungsdateien zu versetzen, um damit zu arbeiten. Wenn ich das richtig sehe, gibt es hier wenig Lösungen. Die versch. Blogposts scheinen immer dieses ziemlich entscheidende Teil zu verpassen.

Vielleicht braucht man ein {% include %} {%render%} für Stylesheets als verfügbar, es sei denn, es wird etwas Magic mit @import geben. Viele Workflows werden durch das Fehlen von Mixins und der Vernunft kaputt gehen und kaputt bleiben, die dieses Feature in die Theme-Entwicklung bringt, wenn man vollwertige Themes erstellt oder Mängel behebt. Und ein ganzer Teil des Internet-Wissens wird sofort obsolet werden für Händler, die keine Ahnung haben und sich nicht darum kümmern, was Breakpoints oder Pre-compiling Sass bedeutet, aber ein Sass-Mixin kopieren und einfügen können.

Ein lokaler Compiler weiß ja nicht, wie er die Inline-Bilder wie {{ 'myimage.jpg' | asset_url }} behandeln und konvertieren soll. -- was ist denn das neue Format, das man verwenden muss, um Assets im Asset-Ordner in geradem css oder sogar lokalem SCSS zu referenzieren? Müssen wir den gesamten Dateipfad einfügen? Man kann diese als Inline-Stile in der Liquid-Datei selbst machen, oder kleine Icons und svgs mann man immer noch als css-Variablen im Stamm erstellen, wie:

:root {
--icon-arrow: url(' {{ 'myimage.jpg' | asset_url }}')
}

Es gibt erhebliche Vorteile von sass gegenüber css, die über die Geschwindigkeit hinausgehen. Es gibt Dinge wie das Einfügen von Media-Queries inline in die Sass-Regeln und die Möglichkeit, Child-Sass-Regeln zu Parents hinzuzufügen. Die Kompilierzeit ist nicht die einzige Überlegung, die man dabei macht. Es macht das Schreiben von Code effizienter und leichter verständlich.

Aber wie unterstützt man das SASS, das innerhalb einer bestehenden .liquid-Datei existiert? Es ist möglich, Sass weiterhin in der lokalen Entwicklung zu verwenden und die Vorteile wie Inline-Media-Queries zu nutzen und dann in eine CSS-Datei zu kompilieren. Themes mit bestehenden Sass-Dateien werden weiterhin unterstützt, allerdings ist es in Zukunft möglicherweise nicht mehr möglich, .scss zu neuen Themes hinzuzufügen.

Warum ist Kompilierzeit ein Faktor in Bezug auf die Endbenutzer-Erfahrung? Es sei denn, ich habe es falsch verstanden, die Sass hätte keinen Einfluss auf die Geschwindigkeit des Editors oder Frontend, da es bereits in CSS bis dahin kompiliert wurde?

Bzgl. das Argument, dass es immer noch lokal verwendet werden kann - ja, aber eine Menge Leute entwickeln nicht lokal. Viele machen die meisten Theme-Bearbeitungen im Theme-Editor. Oft ist das effizienter, als eine lokale Entwicklungsumgebung einzurichten. Aber das Entfernen entfernt auch viele der Vorteile, die Sass bietet, wie die Benutzerfreundlichkeit des Theme-Editors.

Wenn ein Händler eine Einstellung im Editor ändert, kann sich die Ausgabe des (Liquid) Sass ändern, da das Sass in der Regel dynamisch auf Basis der Theme-Einstellungen ist. Der Theme-Editor muss diese Änderung widerspiegeln, was eine Neu-kompilierung des Sass erfordert, was Zeit in Anspruch nimmt, während der Händler auf das Rendern der Vorschau wartet.

Wenn man eine .scss.liquid-Datei statt einer .scss. hat, hat man Zugriff auf die Variable `settings`, mit der man die Stylesheet dynamisch machen können, basierend darauf, wie der Händler die Theme-Einstellungen im Theme-Editor konfiguriert. Es wäre sehr ineffizient, das Sass mit jeder Kombination von Theme-Einstellungen vorkompilieren zu lassen, daher ist die Option, die man hier oft nimmt, die Neu-kompilierung als Reaktion auf eine Änderung im Editor.

Wenn das das Problem ist, dann betrachte mal die Pipeline:

  1. Das Theme wird mit .scss.liquid-Dateien veröffentlicht, die Shopify in .css.liquid-Dateien (unter Beibehaltung des Liquid-Codes) sowie in .min.css (minifizierte CSS-Datei für die Bereitstellung) konvertiert.
  2. Wenn der Entwickler .scss.liquid aktualisiert, konvertiert Shopify erneut .scss.liquid in .css.liquid-Dateien und dann in .min.css-Dateien.
  3. Wenn der Händler die Einstellungen im Theme-Editor ändert, ignoriert Shopify die .scss.liquid-Dateien und kompiliert nur die .css.liquid-Datei wieder zu .min.css mit den Änderungen.

Da die .scss.liquid bereits vor längerer Zeit zu .css.liquid kompiliert wurde, hat das keinen Einfluss auf die Leistung des Theme Editors, wenn der Händler Einstellungen ändert. Aber die Vorteile für den Entwickler bleiben erhalten.

Ein win-win? Computer-Processing Time ist billig. Menschliche Denkzeit nicht... Es gibt so viel, was Sass/Scss kann, was CSS nicht kann. Vielleicht hätte man einen Mechanismus in Betracht ziehen sollen, um die Sass-Version auszuwählen, mit der die Datei kompiliert werden soll (nachdem man sie de-liquidiert haben). Außerdem war der einziger Performance-Benchmark, dass es im Theme-Editor eine zusätzliche Sekunde dauern würde. Wichtiger ist, dass das Theme für den Besucher schnell funktioniert, nicht für den Entwickler. Die End-datei, die für jede Sass/Scss-Datei ausgegeben wird, ist eine CSS-Datei, die jeder Browser lesen und interpretieren kann. Es wäre also egal, wenn die Originaldatei eine Scss-Datei wäre - sie wird nur einmal kompiliert, und dann wird das gleiche CSS (oft minifiziert) serviert, bis die Scss-Datei neu kompiliert werden muss. Dies erhält sowohl die Geschwindigkeit der Website (für den Besucher, wohlgemerkt) als auch die Entwicklungsfreundlichkeit für den Shop-Betreiber und die Mitarbeiter.

Ist es Erleichterung zu wissen, dass wir nicht auf Hunderte von Websites zurückgehen müssen, an denen wir gearbeitet haben, und unsere SCSS manuell zu CSS kompilieren? Es könnte sich lohnen, dies zu verdeutlichen, da die Aussage "Im Moment werden Themes, die .scss-Dateien enthalten, weiterhin funktionieren und Schaufenster werden nicht betroffen sein, wenn ein Theme Sass verwendet" ziemlich verunsichernd sein. Wie wird die Unterstützung von sass innerhalb bestehender .liquid-section/Template-Dateien und den Konvertierungsprozess für eine große Datei wie theme.scss.liquid gewährleistet werden? Wenn man nicht die {% include %} directive in Liquid Stylesheets verfügbar macht, wird sogar die Vorkompilierung von sass zu css für einige klobige Workflows sorgen.

Beispiel: die Ressource von "https://cdn.shopify.com/[..]src.styles.css.liquid?v=1234" kann aufgrund einer Unstimmigkeit im MIME-Typ ("text/x-liquid") mismatch (X-Content-Type-Options: nosniff) blockiert werden. Wie kann man die Verwendung von .css.liquid-Dateien umgehen, wenn das CDN diesen Header aktiviert hat? Antwort: Wenn man versucht, die Datei `.liquid` zu laden, was nicht direkt im Browser funktionieren wird, sollte man lieber die Erweiterung `.liquid` aus der URL entfernen.

Oder denken Händler, dass sie Geld für einen Experten ausgeben müssen, der die Stylesheets des Themes neu entwickelt? Viele sind enttäuscht über diese Entscheidung, weil sie oft Sass-Fanatiker sind. Nicht jeder verwendet Theme Store Themes, die leicht zu aktualisieren sind. Viele bauen benutzerdefinierte Themes, und eines Tages werden alle Websites davon betroffen sein.

Aber Shopify ist anscheinend bestrebt, die backwards compatibility für Themes aufrechtzuerhalten und sicherzustellen, dass Shops durch die Abschaffung von Sass nicht kaputt gehen oder gestört werden. .scss-Dateien werden weiterhin für kompilierte Themes für die absehbare Zukunft unterstützt werden, aber Entwickler werden ermutigt, auf reines CSS zu migrieren, was die Erfahrung für Händler und Partner verbessern kann.

Die Shopify Teams überwachen die Anzahl der Shops, und schauen dass keine Shops kaputt gehen. Die Website wird weiterhin wie erwartet funktionieren, da Shopify sich zur Abwärtskompatibilität für "ältere" Themes mit Sass verpflichtet haben. Was man aber möglicherweise zu einem späteren Zeitpunkt tun muss, ist den Gang zu einer neue Version (oder ein anderes Theme) zu migrieren, die Sass verwendet.

r8r
Shopify Expert
2555 327 940

Danke, ich pflichte dir über weite Strecken bei. Meine 2 Kommentare dazu noch:

1.) Ich hab mich bei der Beantwortung darauf konzentriert: Wie kann ein Laie von SASS auf CSS migrieren? Deine Ergänzungen fügen viele weitere Nuancen ins Feld. Ich kann das auch unterschreiben.

Ergänzung dazu: Im Grunde weckt Shopify möglicherweise falsche Erwartungen bei Händler*innen. Auch, wenn sie über weite Strecken ein Klickibunti Interface bekommen, das für komplette Laien verwendbar sein sollte … ein Online Store ist und bleibt ein Softwareprojekt, bei dem neben Programmier-Know-How auch Wissen inzumindest Bereichen der Juristerei und besser auch noch Marketing vorhanden sein muss, um ein nachhaltiges Ergebnis auf die Beine stellen zu können. Dieses Know How gibt’s aber normalerweise nicht zu dem Null- oder Ramschtarif, auf den Shopify so manche Händler*innen konditioniert hat. Auch in der Community fehlt dann mitunter das Verständnis dafür, dass pro Bono Support über ein paar Zeilen oder Minuten hinaus nicht selbstverständlich ist.
Das Ergebnis sind dann mitunter auch mal in einzelnen Aspekten wirklich minderwertige Lösungen, sofern Händler*innen nicht das Bewusstsein haben, dass für den einen oder anderen Punkt das Geld in Form von Expertise von Leuten mit Erfahrung gut angelegt ist. (Ich will aber schon auch sagen, dass es durchaus auch genügend Händler*innen gibt, die das schon ganz richtig einschätzen.)

2.) Auch ich finde, dass unter den aktuellen Rahmenbedingungen der SASS-Transpiler im Shopify Editor bleiben sollte. Aus denselben Gründen, die du anführst. Komfort und Kompatibilität plus proprietäre Liquid-Integration ganz voran. Eine gangbare Alternative wär aus meiner Sicht, wenn der Transpiler Teil von Themekit würde; allerdings würde das dann auch mit der prominenten Rolle des Theme Code Editors nicht zusammenpassen.

Mario

★ Ja, man kann mich buchen; schreib mir eine Nachricht!
★ Hinterlass gerne ein Like und markiere meine Antwort gegebenenfalls als Lösung. Ich freue ich mich immer über eine Spende an die (Kinder)krebshilfe oder eine kleine Aufmerksamkeit.
Studio Mitte