Wir, das Front-End, verfügen über eine Kategorie von Tools, die die Probleme, mit denen wir konfrontiert sind, nicht lösen, sondern den Lösungsprozess beeinflussen. Ändere es. Die Einstellung zu solchen Tools ist sehr unterschiedlich - angefangen von der Manie im Sinne von "Lass uns dieses Ding überall hinschieben, es ist so cool" und endend mit Ausreden wie "Wenn es das Geschäftsproblem nicht löst, brauchen wir es nicht". Aber heute werden wir über PostCSS sprechen - eines dieser Tools.
Die Hype-Welle ist lange vorbei, in den letzten Jahren wurde sehr wenig über PostCSS gesagt. Viele Anfänger wissen nicht einmal, was es ist. Ich denke, es ist an der Zeit, dieses Tool unter dem Gesichtspunkt des praktischen Einsatzes in den gewöhnlichsten Projekten zu betrachten, in denen Menschen Probleme lösen, anstatt mit modischen Technologien zu spielen.
PostCSS gegen SASS
Oh ... Anscheinend ein paar Worte dazu. Ich denke jetzt hat sich ein seltener Schriftsetzer nicht mit Präprozessoren getroffen. SASS oder mein Lieblings-WENIGER, seltener Stylus, werden sowohl bei großen als auch bei kleinen Projekten verwendet. Jemand versucht, das Beste aus ihnen herauszuholen, jemand verwendet eine minimalistische Menge - Verschachtelung, Variablen, Importe. Auf die eine oder andere Weise helfen diese Tools jedoch bei Syntaxproblemen. Sie erleichtern uns das Schreiben von Code.
Vor ungefähr zwei oder drei Jahren wurde PostCSS ständig mit Präprozessoren verglichen. Und das ist verständlich. Formal können Sie damit das Gleiche tun und eine Syntax erstellen, die bequemer ist als reines CSS. Aber all dies verursachte eine brodelnde Masse, hauptsächlich weil jeder mit Hilfe von PostCSS etwas anderes tat. Unzählige unbekannte Plugins, Millionen von Kombinationen und außer dem Autor dieser oder jener Konfiguration hat niemand verstanden, wie es funktioniert und was es tut. Es ist wie bei Vim oder Emacs - Sie können daraus ein Raumschiff machen, aber es wird sehr schwierig sein, einem anderen Entwickler den Umgang damit beizubringen.
Wenn wir diese Vergleiche jedoch verwerfen, ist PostCSS ein Tool, mit dem wir unser CSS verwenden und etwas damit anfangen können. Niemand stört sich daran, SASS aus Gründen der Syntax zu verwenden, und nach dem Zusammenbau bleiben Sie bei PostCSS und tun etwas mit dem Ergebnis. Sie widersprechen sich nicht.
Alt heißt nicht untätig
In letzter Zeit war es für uns in Mode, Mähdrescher zu entwickeln, die alles können, was uns nur in den Sinn kommt, und deren Entwicklung niemals aufhört. Und wenn es für ein paar Monate keine neuen Commits im Repository gibt, dann ist alles - wir können davon ausgehen, dass es veraltet ist und es jetzt verwendet - nicht comme il faut. Ich werde natürlich übertreiben, aber ich denke, Sie haben selbst bemerkt, wie absurd das manchmal ist.
In der PostCSS-Welt löst normalerweise ein Plugin ein Problem. Sie können hier Elemente der Unix-Philosophie sehen. Daraus folgt eine logische Schlussfolgerung: Wenn das Plugin seine Aufgabe bereits löst, muss nichts mehr damit getan werden. Sie können Plugins finden, die seit Jahren nicht mehr aktualisiert wurden. Dies bedeutet jedoch nicht, dass sie plötzlich die Aufgaben, für die sie erstellt wurden, nicht mehr lösen.
Aber fangen wir an ... Ich habe ein Dutzend Plug-Ins zusammengestellt, die in der Praxis gezeigt haben, dass sie Layout-Designern das Leben vereinfachen und während der Entwicklung Zeit sparen können. Sie können aber jederzeit etwas in die Kommentare einfügen.
Nr. 1. Doiuse
https://github.com/anandthakker/doiuse
Ich denke, wir waren alle mit diesem Problem konfrontiert: Sie schreiben den Code, checken Chrom ein - alles ist in Ordnung. Sie checken in FF ein - ca. Und dann fällt in Mobile Safari alles auseinander. Oder in Edge. Und du sitzt und verstehst nicht, was los ist. Dann starrst du lange auf den Code, trinkst Tee und plötzlich kommt die Erkenntnis, dass einige Eigenschaften in einigen Browsern nicht unterstützt werden. Sie gehen auf caniuse und Sie sehen Bestätigung des Offensichtlichen.
Natürlich erinnern sich die Hände mit der Erfahrung selbst daran, welche Eigenschaften vermieden werden sollten, aber alles passiert. Sie können nicht genug Schlaf bekommen, es kann enge Fristen und Nerven geben, die Liste der Browser, die geändert werden müssen, kann sich ändern. Und dann wird die Erfahrung anfangen zu scheitern. Doiuse ist ein Werkzeug, das in solchen Situationen sehr hilfreich ist.
Das Funktionsprinzip ist einfach: Wir geben ihm eine Liste der Browser und unser CSS. Das Plugin geht in die caniuse-Datenbank und gibt uns in Echtzeit die Antwort, die wir von dem verwendet haben, was nicht unterstützt wird.
Wir können die Liste der Browser direkt in package.json festlegen. Einfach und bequem. PostCSS verwendet eine Browserliste. Wenn Sie diese noch nicht gesehen haben, sieht sie ungefähr so aus:
"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ]
Es gibt auch eine Konfiguration von doiuse selbst, in der Sie erzwingen können, einige Eigenschaftsgruppen zu ignorieren, wenn Sie sicher sind, dass sie nichts beeinflusst. Wenn Sie beispielsweise Polydateien verwenden oder die Unterstützung einer Eigenschaft verlieren, ändert sich nichts:
ignore: [ 'will-change', 'object-fit' ]
Das vom Plugin bereitgestellte Standardprotokoll ist nicht sehr gut lesbar. Es enthält viele Informationen und es ist nicht sehr bequem, sie wahrzunehmen. Dies ist jedoch behebbar. In derselben Konfiguration können wir unsere Funktion ausführen, um ein Protokoll zu erstellen.
Verwenden Sie console.log, um herauszufinden, wie das Objekt funktioniert, das PostCSS an diese Funktion übergibt. Es gibt viele interessante Dinge.
Meine Praxis hat gezeigt, dass die bequemste Option darin besteht, Selektoren und bestimmte Eigenschaften anzuzeigen, die nicht unterstützt werden, ohne Browser und Codezeilen anzugeben. Wenn das Projekt BEM oder einige Analoga verwendet und der Komponentencode in separaten Dateien verteilt ist, können Sie mit diesem Ansatz schnell einen Problemort finden, ohne das Gehirn zu belasten.
onFeatureUsage(info) { const selector = info.usage.parent.selector; const property = `${info.usage.prop}: ${info.usage.value}`; let status = info.featureData.caniuseData.status.toUpperCase(); if (info.featureData.missing) { status = 'NOT SUPPORTED'.red; } else if (info.featureData.partial) { status = 'PARTIAL SUPPORT'.yellow; } console.log(`\n${status}:\n\n ${selector} {\n ${property};\n }\n`); }
Um keine speziellen Zeichenfolgen für Farben in die Konsole zu schreiben, können Sie das Farbpaket anschließen, es ist bequemer damit.
Beim Bauen wird so etwas in der Konsole angezeigt:
NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }
Nr. 2. Autoprefixer
https://github.com/postcss/autoprefixer
Es ist sogar peinlich, über ihn zu sprechen, aber zu oft sehe ich Leute, die 2019 Präfixe mit ihren Händen schreiben und anderen versichern, dass sie genau wissen, welche benötigt werden und welche nicht. Solche Aktionen führen dazu, dass der Code mit einer Reihe unnötiger Präfixe überwächst und völlig unlesbar wird. Dies wirkt sich auf die Arbeitsproduktivität aus. Wenn Sie jedoch die Unterstützung von Dinosauriern benötigen, können Sie immer etwas vergessen. Es lohnt sich also, bei der Lösung dieses Problems die Handarbeit loszuwerden.
Der Autoprefixer arbeitet mit derselben caniuse-Datenbank, verwendet dieselbe Browserliste und kann dem CSS die Präfixe hinzufügen, die in den von uns angegebenen Browsern wirklich benötigt werden. Gleichzeitig wird der Code selbst sauberer und die Arbeit geht schneller.
Nummer 3. Stylelint
https://github.com/stylelint/stylelint
Wenn Sie viel und schnell drucken, machen Sie früher oder später viele Fehler, ohne sie vollständig zu bemerken. Das Auge ist verschwommen. Im Fall von CSS kann dies einen lustigen (eigentlich nicht) Effekt haben, wenn Sie in den Browser schauen - Sie sehen ein Problem mit dem Layout. Sie sehen sich den Code an - er ist nicht da. Sie schauen in den Browser - es ist. Aber im Code - nein. Infolgedessen können Sie lange nach einem schwierigen Problem suchen, ohne zu bemerken, dass Sie gerade den Kopf herumbekommen haben. Um dies zu verhindern, erfand Linter.
Stylelint ist eine beliebte Option. Er weiß, wie man mit der Syntax der wichtigsten Präprozessoren arbeitet, er kennt die neuesten Trends in CSS, er kann sie nach seinem Geschmack anpassen - Konfigurationen ähneln denen von Eslint. Formal kann dieses Tool ohne PostCSS allein verwendet werden, aber hier nicht zu erwähnen, wäre falsch.
Nummer 4. Postcss-Flexbugs-Fixes
https://github.com/luisrudge/postcss-flexbugs-fixes
Oder im weiteren Sinne Postcss-Fixes , die dieses Plugin enthalten. Langsam, aber sicher ersetzen Biegungen den alten Ansatz für das Layout auf Schwimmern. Das ist gut, aber wir alle wissen, dass eine Reihe von Fehlern damit verbunden sind. Sie werden im Flexbugs- Repository beschrieben. Einige von ihnen erfordern besondere Aufmerksamkeit, aber es gibt auch einige, die so einfach sind, dass sie ständig aus Ihrem Kopf fliegen. Beispielsweise ignoriert der IE die Berechnungsfunktion in der Kurzform für die Flex-Eigenschaft. Dies ist nicht so oft notwendig, aber wenn nötig, können Ihre Hände eine gekürzte Version schreiben und dann müssen Sie lange darüber nachdenken, wo das Problem liegt. Glücklicherweise kann dies automatisch behoben werden. Das Postcss-Flexbugs-Fixes-Plugin hilft dabei.
Im Berechnungsbeispiel werden Fragmente wie diese im Code gefunden:
.foo { flex: 1 0 calc(1vw – 1px); }
Und setzen Sie sie ein:
.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); }
Einfach und bequem.
Nr. 5. Postcss-preset-env
https://github.com/csstools/postcss-preset-env
Da es sich um Browserunterstützung handelt, ist es nicht unangebracht, über postcss-preset-env zu sprechen. Zuvor spielte cssnext die gleiche Rolle. Dieses Plugin ist nützlich, wenn Sie an neuen Trends in CSS interessiert sind.
Viele der Innovationen können mit den alten Methoden technisch umgesetzt werden, sie sind einfach lang, ausführlich und hässlich. Mit Preset-env können Sie Code auf neue Weise schreiben, Zeit sparen und ihn dann in eine alte zuverlässige Version konvertieren. Natürlich sind einige Dinge wie benutzerdefinierte Eigenschaften in älteren Browsern überhaupt nicht implementiert, daher werden dort Fallbacks verwendet.
Wie Sie dem Namen des Instruments entnehmen können, ähnelt es dem bei Babel voreingestellten Namen. Hier ist alles gleich - es gibt viele Konverter, die zu einem stabilen Satz zusammengebaut sind. Einige Transformationen erfordern die anschließende Verbindung von Polyphile-Skripten auf dem Client, die meisten werden jedoch ausschließlich von CSS implementiert. Soweit ich weiß, werden für Stage2 + keine Skripte benötigt. Auf jeden Fall bin ich nicht auf ihre Bedürfnisse gestoßen. Korrigieren Sie mich, wenn ich dort etwas verpasst habe.
Nr. 6. Postcss-Animation
https://github.com/zhouwenbin/postcss-animation
Oft höre ich von verschiedenen Leuten (meistens Backends, die nicht sehr stark in CSS sind), dass sie separate Animationen von animate.css verwenden möchten , halte es jedoch für eine schlechte Idee, die gesamte Bibliothek zu verbinden. Es ist ziemlich logisch. Infolgedessen verbringen sie viel Zeit damit, diese Animationen selbst zu wiederholen.
Das Postcss-Animations-Plugin beschleunigt diesen Prozess erheblich. Wir schreiben nur den Namen der Animation, zum Beispiel:
.foo { animation-name: bounce; }
Und er ruft die Implementierung aus animate.css auf und fügt sie in den Code ein.
.foo { animation-name: bounce; } @keyframes bounce { from, 20%, 53%, 80%, to { animation-timing-function: cubic-bezier(0.215, 0.610, 0.355, 1.000); transform: translate3d(0,0,0); } 40%, 43% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -30px, 0); } 70% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -15px, 0); } 90% { transform: translate3d(0,-4px,0); } }
Nummer 7. Listenselektoren
https://github.com/davidtheclark/list-selectors
Wenn Sie mehrere Schriftsetzer und viele Stile haben, stellt sich bei der Codeüberprüfung die Frage, dass es schön wäre, manchmal mit Ihren Augen das Gesamtbild mit all den Selektoren zu sehen, die wir haben. Wissen, welche IDs verwendet werden, ob es Tag-Selektoren gibt oder wie gut die akzeptierte Methodik befolgt wird. Dies ist besonders wichtig, wenn Sie den Anfängercode überprüfen, der seltsame Dinge schreiben kann, die formal funktionieren, aber tatsächlich gegen die akzeptierten Vereinbarungen verstoßen (weit davon entfernt, dass diese Vereinbarungen gut festgelegt sind und die Möglichkeit besteht, solche Dinge zu automatisieren). Scrollen Sie selbst durch zahlreiche Stylesheets, um die Angemessenheit der Selektoren für eine lange Zeit zu überprüfen. Wir brauchen eine Möglichkeit, sie zu isolieren und separat zu zeigen. Listenselektoren lösen nur dieses Problem.
Genau wie bei doiuse können Sie mit diesem Plugin Informationen für die Anzeige vorbereiten. Sie können nur anzeigen, was Sie interessiert, oder alles in verschiedenen Farben malen. Als Beispiel:
require('list-selectors').plugin((list) => { const inspect = require('util').inspect; console.log('SELECTORS:'.blue); console.log(inspect(list.selectors, { maxArrayLength: null }).blue); console.log('IDS:'.red); console.log(inspect(list.simpleSelectors.ids, { maxArrayLength: null }).red); })
In diesem Beispiel wird eine lange, lange Liste von Selektoren erstellt:
SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . .
Nummer 8. Unveränderliches CSS
https://github.com/johno/immutable-css
Eine andere Sache, auf die Sie achten sollten, ist das Unterbrechen von Stilen aus Bibliotheken von Drittanbietern. Wenn wir eine Art Bibliothek verbunden haben und dann anfangen, unsere eigenen Stile für Selektoren daraus zu schreiben, erhalten wir am Ende verwirrenden Code, in dem wir nicht erkennen können, woher er stammt. Dies kann zu zufälligen Fehlern führen, die dann aus heiterem Himmel zu viel Zeit in Anspruch nehmen. Je öfter wir etwas neu definieren, desto schwieriger ist es, letztendlich zu verstehen, was passiert, obwohl das Problem selbst, das gelöst werden muss, sehr einfach sein kann. In dieser Situation kann ein Tool namens unveränderliches CSS nützlich sein.
Im Allgemeinen ist das Prinzip seiner Arbeit einfach: Es nimmt Dateien mit Stilen auf. Wenn es Übereinstimmungen mit Selektoren findet, wird es empört:
! .button was mutated 2 times [line 93, col 1]: /css/basscss.css [line 3, col 1]: /css/custom.css [immutable-css] ! .left was mutated 2 times [line 291, col 1]: /css/basscss.css [line 4, col 1]: /css/custom.css [immutable-css]
Das einzige Problem mit diesem Tool ist, dass es keine Nicht-CSS-Syntax unterstützt. Wenn also Präprozessoren im Projekt verwendet werden, müssen bereits zusammengestellte Dateien verglichen werden. Im Allgemeinen ist dies jedoch nicht so wichtig, wenn lediglich sichergestellt werden soll, dass niemand versehentlich die Stile aus einer Bibliothek eines Drittanbieters neu schreibt.
Nr. 9. Tschüss!
https://github.com/AoDev/css-byebye
Ich denke, jeder ist mit der Situation vertraut, wenn wir einer Arbeitsstelle nach und nach einige Komponenten hinzufügen. Einige von ihnen gehen sofort in die Produktion, andere sitzen lange und warten, bis sie an der Reihe sind (zum Beispiel haben wir uns versöhnt, wir haben das Backend noch nicht fertiggestellt). Etwas kann ein Experiment oder eine vorübergehende Lösung für die Feiertage sein. Es mag viele Situationen geben, aber sie werden durch die Tatsache vereint, dass wir eine Reihe von Komponenten haben und nur ein kleiner Teil davon auf dem Kampfgelände verwendet wird. Es wäre schön, alles, was nicht verwendet wird, aus der aktuellen Baugruppe zu entfernen. Dies kann die Größe erheblich reduzieren und in Zukunft Kopfschmerzen reduzieren, wenn beispielsweise eine Neugestaltung erforderlich ist und die Frage lautet, was von alledem jetzt wirklich neu geschrieben werden muss und was nicht.
Es gibt verschiedene Ansätze für dieses Problem. Uncss fällt mir sofort ein. Dieses Tool erkennt automatisch, welche Stile auf Seiten verwendet werden, und entfernt unnötige Stile. In der Praxis führt dies jedoch fast immer dazu, dass niemand weiß, was tatsächlich verwendet wird und was nicht. Ich bezweifle auch ständig, ob dieses Tool etwas Überflüssiges gelöscht hat. Aber das ist wahrscheinlich meine Paranoia. Obwohl ...
Bye-bye ist ein einfacheres Tool, mit dem wir selbst eine Liste von Selektoren füttern, die aus CSS entfernt werden sollen. Und Sie können reguläre Ausdrücke verwenden. Wenn Sie BEM oder ähnliches verwenden, können Sie mit einem einfachen Regular einen Block mit allem, was damit zu tun hat, löschen. Tschüss!
Dieser Ansatz erwies sich als recht praktisch. Es ist sofort klar, welche Stile noch nicht verwendet wurden oder als unnötig entfernt wurden, während alle Quellen vorhanden sind, alle Einstellungen in einer Datei, nichts verloren geht, es nicht schwierig ist, mehrere verschiedene Assemblys zu erstellen, und vor allem ist die Lösung einfach und vorhersehbar.
Nr. 10. Postcss-Trolling
https://github.com/juanfran/postcss-trolling
Alle vorherigen Tools können die Produktivität Ihrer Layout-Designer leicht steigern, aber dieses liefert einfach phänomenale Ergebnisse. Ich kann es nur empfehlen.
Fazit
PostCSS ist eine gute Hilfe für einen Layoutdesigner. Wenn sie nicht missbraucht werden, natürlich. Für viele zeitaufwändige Probleme gibt es vorgefertigte Lösungen in Form von Plug-Ins, und obwohl sie sich oft nicht entwickeln und verlassen erscheinen, beeinträchtigt dies ihre Verwendung nicht.