Schließung der Lücke zwischen CSS und JavaScript: CSS-Module, PostCSS und die Zukunft von CSS

Im vorherigen Beitrag dieser zweiteiligen Serie haben wir die Landschaft von CSS-in-JS erkundet und festgestellt, dass CSS-in-JS nicht nur kritische Stile erzeugen kann, sondern dass einige Bibliotheken nicht einmal eine Laufzeit haben. Wir haben gesehen, dass sich die Benutzererfahrung durch clevere Optimierungen erheblich verbessern lässt, weshalb sich diese Serie auf die Entwicklererfahrung (die Erfahrung der Stilerstellung) konzentriert.

In diesem Teil werden wir die Tools für "Plain ol' CSS" untersuchen, indem wir die `Photo`-Komponente aus unserem bestehenden Beispiel refaktorieren.

Kontroverse und #heißesDrama

Eine der berühmtesten CSS-Debatten ist, ob die Sprache so ist, wie sie ist, in Ordnung ist. Ich denke, diese Debatte bleibt lebendig, weil beide Seiten etwas Wahres an sich haben. Zum Beispiel ist es zwar wahr, dass CSS ursprünglich dazu gedacht war, ein Dokument zu gestalten, anstatt Komponenten einer Anwendung, aber es ist auch wahr, dass kommende CSS-Funktionen dies dramatisch ändern werden und dass viele CSS-Fehler daraus entstehen, dass Styling als nachträglicher Gedanke behandelt wird, anstatt sich Zeit zu nehmen, es richtig zu lernen oder jemanden einzustellen, der gut darin ist.

Ich glaube nicht, dass die CSS-Tools selbst die Quelle der Kontroverse sind; wir werden sie wahrscheinlich zumindest bis zu einem gewissen Grad immer verwenden. Aber Ansätze wie CSS-in-JS sind anders, da sie die Unzulänglichkeiten von CSS mit clientseitigem JavaScript beheben. CSS-in-JS ist jedoch nicht der einzige Ansatz; es ist lediglich der neueste. Erinnern Sie sich, als wir ähnliche Debatten über Präprozessoren wie Sass führten? Sass hat Funktionen wie Mixins, die nicht auf einem CSS-Vorschlag basieren (ganz zu schweigen von der gesamten eingerückten Syntax). Sass wurde jedoch in einer ganz anderen Zeit geboren und hat einen Punkt erreicht, an dem es nicht mehr fair ist, ihn in die Debatte einzubeziehen, weil sich die Debatte selbst geändert hat – also begannen wir, CSS-in-JS zu kritisieren, weil es ein leichteres Ziel ist.

Ich denke, wir sollten Werkzeuge verwenden, die es uns ermöglichen, vorgeschlagene Syntax heute zu verwenden. Nehmen wir JavaScript Promises als Analogie. Diese Funktion wird von Internet Explorer nicht unterstützt, daher fügen viele Leute ein Polyfill dafür hinzu. Der Sinn von Polyfills besteht darin, dass wir so tun können, als ob die Funktion überall unterstützt wird, indem wir native Browser-Implementierungen durch einen Patch ersetzen. Dasselbe gilt für das Transpilieren neuer Syntax mit Tools wie Babel. Wir können es heute verwenden, weil der Code in eine ältere, gut unterstützte Syntax kompiliert wird. Dies ist ein guter Ansatz, da er uns ermöglicht, zukünftige Funktionen heute zu nutzen und gleichzeitig JavaScript voranzutreiben, so wie Präprozessoren wie Sass CSS vorangetrieben haben.

Mein Beitrag zur CSS-Kontroverse ist, dass wir Werkzeuge verwenden sollten, die es uns ermöglichen, zukünftiges CSS heute zu nutzen.

Präprozessoren

Wir haben bereits ein wenig über CSS-Präprozessoren gesprochen, daher lohnt es sich, sie etwas detaillierter zu diskutieren und wie sie in die CSS-in-JS-Unterhaltung passen. Wir haben Sass, Less und PostCSS (unter anderem), die unseren CSS-Code mit allen möglichen neuen Funktionen ausstatten können.

Für unser Beispiel werden wir uns nur mit Verschachtelung beschäftigen, einer der häufigsten und leistungsfähigsten Funktionen von Präprozessoren. Ich schlage die Verwendung von PostCSS vor, da es uns eine granulare Kontrolle über die Features gibt, die wir hinzufügen, was genau das ist, was wir in diesem Fall brauchen. Das PostCSS-Plugin, das wir verwenden werden, ist postcss-nesting, da es dem tatsächlichen Vorschlag für native CSS-Verschachtelung folgt.

Der beste Weg, PostCSS mit unserem Kompilierungstool webpack zu verwenden, ist, postcss-loader nach css-loader in der Konfiguration hinzuzufügen. Beim Hinzufügen von Loadern nach css-loader ist es wichtig, sie in den css-loader-Optionen zu berücksichtigen, indem importLoaders auf die Anzahl der nachfolgenden Loader gesetzt wird, was in diesem Fall 1 ist.

{
  test: /\.css$/,
  use: [
    'style-loader',
    {
      loader: 'css-loader',
      options: {
        importLoaders: 1,
      },
    },
    'postcss-loader',
  ],
}

Dies stellt sicher, dass CSS-Dateien, die aus anderen CSS-Dateien importiert werden, ebenfalls mit postcss-loader verarbeitet werden.

Nachdem wir postcss-loader eingerichtet haben, werden wir postcss-nesting installieren und es in die PostCSS-Konfiguration aufnehmen.

yarn add postcss-nesting

Es gibt viele Möglichkeiten, PostCSS zu konfigurieren. In diesem Fall werden wir eine Datei namens postcss.config.js im Stammverzeichnis unseres Projekts hinzufügen.

module.exports = {
  plugins: {
    "postcss-nesting": {},
  },
}

Jetzt können wir eine CSS-Datei für unsere Photo-Komponente schreiben. Nennen wir sie Photo.css.

.photo {
  width: 200px;
  &.rounded {
    border-radius: 1rem;
  }
}

@media (min-width: 30rem) {
  .photo {
    width: 400px;
  }
}

Fügen wir auch eine Datei namens utils.css hinzu, die eine Klasse zum visuellen Ausblenden von Elementen enthält, wie wir es im ersten Teil dieser Serie besprochen haben.

.visuallyHidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
  white-space: nowrap;
}

Da unsere Komponente auf diesen Utility angewiesen ist, fügen wir utils.css zu Photo.css hinzu, indem wir eine @import-Anweisung am Anfang hinzufügen.

@import url('utils.css');

Dies stellt sicher, dass webpack utils.css erfordert, dank css-loader. Wir können utils.css überall platzieren und den @import-Pfad anpassen. In diesem speziellen Fall ist es ein Geschwister von Photo.css.

Als Nächstes importieren wir Photo.css in unsere JavaScript-Datei und verwenden die Klassen, um unsere Komponente zu gestalten.

import React from 'react'
import { getSrc, getSrcSet } from './utils'
import './Photo.css'

const Photo = ({ publicId, alt, rounded }) => (
  <figure>
    <img
      className={rounded ? 'photo rounded' : 'photo'}
      src={getSrc({ publicId, width: 200 })}
      srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
      sizes="(min-width: 30rem) 400px, 200px"
    />
    <figcaption className="visuallyHidden">{alt}</figcaption>
  </figure>
)

Photo.defaultProps = {
  rounded: false,
}

export default Photo

Dies wird zwar funktionieren, aber unsere Klassennamen sind viel zu einfach und werden mit ziemlicher Sicherheit mit anderen, die nichts mit unserer .photo-Klasse zu tun haben, kollidieren. Eine Möglichkeit, dies zu umgehen, ist die Verwendung einer Namensmethodik wie BEM, um unsere Klassen umzubenennen (z. B. photo_rounded und photo__what-is-this--i-cant-even), um Kollisionen zu vermeiden, aber Komponenten werden schnell komplex und Klassennamen werden lang, abhängig von der Gesamtkomplexität des Projekts.

Lernen Sie CSS Modules kennen.

CSS-Module

Einfach ausgedrückt sind CSS-Module CSS-Dateien, in denen alle Klassennamen und Animationen standardmäßig lokal beschränkt sind. Sie sehen fast wie normales CSS aus. Zum Beispiel können wir unsere Photo.css und utils.css Dateien als CSS-Module verwenden, ohne sie überhaupt zu ändern, indem wir einfach modules: true an die Optionen von css-loader übergeben.

{
  loader: 'css-loader',
  options: {
    importLoaders: 1,
    modules: true,
  },
}

CSS-Module sind eine sich entwickelnde Funktion und könnten noch ausführlicher diskutiert werden. Robins dreiteilige Serie dazu ist ein guter Überblick und eine Einführung.

Während CSS-Module selbst regelmäßigem CSS sehr ähnlich sehen, ist die Art und Weise, wie wir sie *verwenden*, ziemlich anders. Sie werden in JavaScript als Objekte importiert, wobei Schlüssel den erstellten Klassennamen entsprechen und Werte eindeutige Klassennamen sind, die automatisch für uns generiert werden und den Geltungsbereich auf eine Komponente beschränken.

import React from 'react'
import { getSrc, getSrcSet } from './utils'
import styles from './Photo.css'
import stylesUtils from './utils.css'

const Photo = ({ publicId, alt, rounded }) => (
  <figure>
    <img
      className={rounded
        ? `${styles.photo} ${styles.rounded}`
        : styles.photo}
      src={getSrc({ publicId, width: 200 })}
      srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
      sizes="(min-width: 30rem) 400px, 200px"
    />
    <figcaption className={stylesUtils.visuallyHidden}>{alt}</figcaption>
  </figure>
)

Photo.defaultProps = {
  rounded: false,
}

export default Photo

Da wir utils.css als CSS-Modul verwenden, können wir die @import-Anweisung am Anfang von Photo.css entfernen. Beachten Sie auch, dass die Verwendung von camelCase zur Formatierung von Klassennamen deren Verwendung in JavaScript erleichtert. Wenn wir Bindestriche verwendet hätten, müssten wir Dinge vollständig ausschreiben, wie stylesUtils['visually-hidden'].

CSS-Module haben zusätzliche Funktionen wie Komposition. Im Moment importieren wir utils.css in Photo.js, um unsere Komponentenstile anzuwenden, aber nehmen wir an, wir möchten die Verantwortung für das Styling der Bildunterschrift stattdessen an Photo.css übertragen. Auf diese Weise ist styles.caption für unseren JSX-Code nur ein weiterer Klassenname; er blendet das Element zufällig visuell aus, aber er könnte in Zukunft anders gestaltet werden. In jedem Fall wird Photo.css diese Entscheidungen treffen.

Fügen wir also einen Bildunterschriftenstil zu Photo.css hinzu, um die Eigenschaften des visuallyHidden-Dienstprogramms mit composes zu erweitern.

.caption {
  composes: visuallyHidden from './utils.css';
}

Wir könnten auch weitere Regeln zu dieser Klasse hinzufügen, aber das ist alles, was wir in diesem Fall brauchen. Jetzt müssen wir utils.css nicht mehr in Photo.js importieren; wir können stattdessen einfach styles.caption verwenden.

<figcaption className={styles.caption}>{alt}</figcaption>

Wie funktioniert das? Werden die Stile von visuallyHidden auf caption kopiert? Untersuchen wir den Wert von styles.caption – wow, *zwei* Klassen! Das stimmt: eine stammt von visuallyHidden und die andere wendet alle anderen Stile an, die wir zu caption hinzufügen. CSS-in-JS macht es zu einfach, Stile mit Bibliotheken wie polished zu duplizieren, aber CSS-Module ermutigen Sie, bestehende Stile wiederzuverwenden. Sie müssen keine neue VisuallyHidden React-Komponente erstellen, um nur mehrere CSS-Regeln anzuwenden.

Nehmen wir es noch weiter, indem wir diese unangenehme Klassenkomposition untersuchen.

rounded
  ? `${styles.photo} ${styles.rounded}`
  : styles.photo

Es gibt Bibliotheken für diese Situationen, wie classnames, die für komplexere Klassenkompositionen nützlich sind. In unserem Beispiel können wir jedoch weiterhin composes verwenden und .rounded in .roundedPhoto umbenennen.

.photo {
  width: 200px;
}

.roundedPhoto {
  composes: photo;
  border-radius: 1rem;
}

@media (min-width: 30rem) {
  .photo {
    width: 400px;
  }
}

.caption {
  composes: visuallyHidden from './utils.css';
}

Jetzt können wir die Klassennamen auf unsere Komponente auf eine viel besser lesbare Weise anwenden.

rounded ? styles.roundedPhoto : styles.photo

Aber Moment, was ist, wenn wir versehentlich die .roundedPhoto-Regel *vor* .photo platzieren und einige Regeln von .photo Regeln von .roundedPhoto aufgrund der Spezifität überschreiben? Machen Sie sich keine Sorgen, CSS-Module verhindern, dass wir Klassen komponieren, die *nach* der aktuellen Klasse definiert sind, indem sie einen Fehler wie diesen ausgeben.

referenced class name "photo" in composes not found (2:3)

  1 | .roundedPhoto {
> 2 |   composes: photo;
    |   ^
  3 |   border-radius: 1rem;
  4 | }

Beachten Sie, dass es generell eine gute Idee ist, eine Dateinamenskonvention für CSS-Module zu verwenden, z. B. die Erweiterung .module.css, da es üblich ist, auch globale Stile anwenden zu wollen.

Dynamische Stile

Bisher haben wir bedingt vordefinierte Stilgruppen angewendet, was als bedingtes Styling bezeichnet wird. Was ist, wenn wir auch den Randradius der gerundeten Fotos fein abstimmen wollen? Dies wird als dynamisches Styling bezeichnet, da wir den Wert nicht im Voraus kennen; er kann sich ändern, während die Anwendung läuft.

Es gibt nicht viele Anwendungsfälle für dynamisches Styling – normalerweise stylen wir bedingt, aber in Fällen, in denen wir dies benötigen, wie würden wir damit umgehen? Während wir uns mit Inline-Stilen behelfen könnten, ist eine native Lösung für diese Art von Problemen Custom Properties (auch bekannt als CSS-Variablen). Ein wirklich wertvoller Aspekt dieser Funktion ist, dass Browser Stile mit benutzerdefinierten Eigenschaften aktualisieren, wenn JavaScript sie ändert. Wir können eine benutzerdefinierte Eigenschaft auf einem Element über Inline-Stile setzen, was bedeutet, dass sie auf dieses Element und nur dieses Element beschränkt ist.

style={typeof borderRadius !== 'undefined' ? {
  '--border-radius': borderRadius,
} : null}

In Photo.css können wir diese benutzerdefinierte Eigenschaft verwenden, indem wir var() verwenden und den Standardwert als zweites Argument übergeben.

.roundedPhoto {
  composes: photo;
  border-radius: var(--border-radius, 1rem);
}

Für JavaScript ist es nur die Übergabe eines dynamischen Parameters an CSS, und wenn CSS übernimmt, kann es den Wert unverändert anwenden, einen neuen Wert daraus mit calc() berechnen usw.

Fallback

Zum Zeitpunkt des Schreibens ist die Browserunterstützung für benutzerdefinierte Eigenschaften... nun, entscheiden Sie selbst. Die Nichtunterstützung dieser Browser ist für eine reale Anwendung (wahrscheinlich) ausgeschlossen, aber denken Sie daran, dass einige Stile weniger wichtig sind als andere. In diesem Fall ist es kein großes Problem, wenn der Randradius unter IE immer 1rem ist. Die Anwendung muss nicht in jedem Browser gleich aussehen.

Um automatisch Fallbacks für alle benutzerdefinierten Eigenschaften bereitzustellen, installieren wir postcss-custom-properties und fügen es unserer PostCSS-Konfiguration hinzu.

yarn add postcss-custom-properties

module.exports = {
  plugins: {
    'postcss-nesting': {},
    'postcss-custom-properties': {},
  },
}

Dies generiert einen Fallback für unsere border-radius-Regel.

.roundedPhoto {
  composes: photo;
  border-radius: 1rem;
  border-radius: var(--border-radius, 1rem);
}

Browser, die var() nicht verstehen, ignorieren diese Regel und verwenden die vorherige. Lassen Sie sich vom Namen des Plugins nicht täuschen; es verbessert die Unterstützung für benutzerdefinierte Eigenschaften nur *teilweise*, indem es statische Fallbacks bietet. Der dynamische Aspekt kann nicht mit Polyfills abgedeckt werden.

Werte für JavaScript verfügbar machen

Im vorherigen Teil dieser Serie haben wir untersucht, wie CSS-in-JS uns ermöglicht, fast alles zwischen CSS und JavaScript zu teilen, am Beispiel von Media Queries. Hier ist kein Weg möglich, oder?

Dank Jonathan Neal können Sie das!

Treffen Sie zuerst postcss-preset-env, den Nachfolger von cssnext. Es ist ein PostCSS-Plugin, das als Preset fungiert, ähnlich wie @babel/preset-env. Es enthält Plugins wie postcss-nesting, postcss-custom-properties, autoprefixer usw., sodass wir zukünftiges CSS heute nutzen können. Es teilt die Plugins in vier Stufen der Standardisierung auf. Einige der Funktionen, die ich Ihnen zeigen möchte, sind nicht im Standardbereich (Stufe 2+) enthalten, daher werden wir die benötigten explizit aktivieren.

yarn add postcss-preset-env

module.exports = {
  plugins: {
    'postcss-preset-env': {
      features: {
        'nesting-rules': true,
        'custom-properties': true, // already included in stage 2+
        'custom-media-queries': true, // oooh, what's this? :)
      },
    },
  },
}

Beachten Sie, dass wir unsere bestehenden Plugins ersetzt haben, da diese postcss-preset-env-Konfiguration sie enthält, was bedeutet, dass unser bestehender Code wie zuvor funktionieren sollte.

Die Verwendung von benutzerdefinierten Eigenschaften in Media Queries ist ungültig, da sie dafür nicht gedacht waren. Stattdessen verwenden wir benutzerdefinierte Media Queries.

@custom-media --photo-breakpoint (min-width: 30em);

.photo {
  width: 200px;
}

@media (--photo-breakpoint) {
  .photo {
    width: 400px;
  }
}

Obwohl diese Funktion im experimentellen Stadium ist und daher in *keinem* Browser unterstützt wird, funktioniert sie dank postcss-preset-env einfach! Ein Nachteil ist, dass PostCSS pro Datei arbeitet, sodass nur Photo.css --photo-breakpoint verwenden kann. Lassen Sie uns etwas dagegen tun.

Jonathan Neal hat kürzlich eine importFrom-Option in postcss-preset-env implementiert, die auch an andere unterstützende Plugins wie postcss-custom-properties und postcss-custom-media weitergegeben wird. Ihr Wert kann vieles sein, aber für unseren Beispielzwecke ist es ein Pfad zu einer Datei, die in die von PostCSS verarbeiteten Dateien importiert wird. Nennen wir sie global.css und verschieben unsere benutzerdefinierte Media Query dorthin.

@custom-media --photo-breakpoint (min-width: 30em);

...und definieren wir importFrom und geben den Pfad zu global.css an.

module.exports = {
  plugins: {
    'postcss-preset-env': {
      importFrom: 'src/global.css',
      features: {
        'nesting-rules': true,
        'custom-properties': true,
        'custom-media-queries': true,
      },
    },
  },
}

Jetzt können wir die Zeile @custom-media am Anfang von Photo.css löschen und unser --photo-breakpoint-Wert funktioniert weiterhin, da postcss-preset-env den aus global.css verwendet, um ihn zu kompilieren. Dasselbe gilt für benutzerdefinierte Eigenschaften und benutzerdefinierte Selektoren.

Wie machen wir ihn für JavaScript verfügbar? Wenn experimentelle Funktionen wie benutzerdefinierte Media Queries standardisiert und in wichtigen Browsern implementiert werden, können wir sie nativ aus CSS abrufen. Zum Beispiel würden wir so auf eine benutzerdefinierte Eigenschaft namens --font-family zugreifen, die auf :root definiert ist.

const rootStyles = getComputedStyle(document.body)
const fontFamily = rootStyles.getPropertyValue('--font-family')

Wenn benutzerdefinierte Media Queries standardisiert werden, können wir wahrscheinlich auf ähnliche Weise darauf zugreifen, aber in der Zwischenzeit müssen wir eine Alternative finden. Wir könnten die exportTo-Option verwenden, um eine JavaScript- oder JSON-Datei zu generieren, die wir in JavaScript importieren würden. Das Problem ist jedoch, dass webpack versuchen würde, sie zu laden, *bevor* sie generiert wird. Selbst wenn wir sie generieren würden, bevor wir webpack ausführen, würde jede Aktualisierung von global.css dazu führen, dass webpack zweimal neu kompiliert wird, einmal zur Generierung der Ausgabedatei und einmal zum Importieren. Ich wollte eine Lösung, die von ihrer Implementierung unbeeinflusst ist.

Für diese Serie habe ich einen brandneuen webpack-Loader namens css-customs-loader speziell für Sie erstellt! Dies erleichtert diese Aufgabe: alles, was wir tun müssen, ist, ihn in unserer webpack-Konfiguration vor css-loader einzufügen.

{
  test: /\.css$/,
  use: [
    'style-loader',
    'css-customs-loader',
    {
      loader: 'css-loader',
      options: {
        importLoaders: 1,
      },
    },
    'postcss-loader',
  ],
}

Dies macht benutzerdefinierte Media Queries sowie benutzerdefinierte Eigenschaften für JavaScript verfügbar. Wir können darauf zugreifen, indem wir einfach global.css importieren.

import React from 'react'
import { getSrc, getSrcSet } from './utils'
import styles from './photo.module.css'
import { customMedia } from './global.css'

const Photo = ({ publicId, alt, rounded, borderRadius }) => (
  <figure>
    <img
      className={rounded ? styles.roundedPhoto : styles.photo}
      style={
        typeof borderRadius !== 'undefined'
          ? { ['--border-radius']: borderRadius }
          : null
      }
      src={getSrc({ publicId, width: 200 })}
      srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
      sizes={`${customMedia['--photo-breakpoint']} 400px, 200px`}
    />
    <figcaption className={styles.caption}>{alt}</figcaption>
  </figure>
)

Photo.defaultProps = {
  rounded: false,
}

export default Photo

Das ist alles!

Ich habe ein Repository erstellt, das alle in dieser Serie besprochenen Konzepte demonstriert. Sein Readme enthält auch einige fortgeschrittene Tipps zu dem in diesem Beitrag beschriebenen Ansatz.

Repo ansehen

Fazit

Man kann mit Sicherheit sagen, dass Tools wie CSS Modules und PostCSS sowie kommende CSS-Funktionen den Herausforderungen von CSS gewachsen sind. Welche Seite der CSS-Debatte Sie auch immer vertreten, dieser Ansatz ist eine Erkundung wert.

Ich habe einen starken Hintergrund in CSS-in-JS, bin aber sehr anfällig für Hype, sodass es für mich sehr schwer ist, mit dieser Welt Schritt zu halten. Während es prägnant sein kann, Stile neben dem Verhalten zu haben, vermischt es auch zwei sehr unterschiedliche Sprachen – CSS ist im Vergleich zu JavaScript sehr wortreich. Dies hat mich dazu bewogen, *weniger* CSS zu schreiben, da ich vermeiden wollte, dass die Datei zu überladen wird. Dies mag eine Frage der persönlichen Präferenz sein, aber ich wollte nicht, dass dies ein Problem darstellt. Die Verwendung einer separaten Datei für CSS gab meinem Code endlich etwas Luft.

Obwohl die Beherrschung dieses Ansatzes möglicherweise nicht so einfach ist wie bei CSS-in-JS, glaube ich, dass er auf lange Sicht lohnender ist. Er wird Ihre CSS-Kenntnisse verbessern und Sie besser auf seine Zukunft vorbereiten.