Next.js: [RFC] CSS-Unterstützung

Erstellt am 4. Sept. 2019  ·  60Kommentare  ·  Quelle: vercel/next.js

Tore

  • Unterstützt globale CSS-Effekte (z. B. Bootstrap, Normalize.css, UX-bereitgestellt usw.)
  • Unterstützt stabiles CSS auf Komponentenebene
  • Änderungen des Hot-Reload-Stils in der Entwicklung (keine Seitenaktualisierung oder Statusverlust)
  • Kann Code-Split für die kritische CSS-Extraktion in der Produktion durchführen
  • Nutzen Sie vorhandene Konventionsbenutzer, mit denen Sie bereits vertraut sind (z. B. Create React App).
  • Behalten Sie die vorhandene Unterstützung für styled-jsx , die möglicherweise optimiert ist

Hintergrund

Das Importieren von CSS in JavaScript-Anwendungen ist eine Praxis, die von modernen Bundlern wie Webpack populär gemacht wird.

Es ist jedoch schwierig, CSS-Importe richtig zu machen: Im Gegensatz zu JavaScript ist alles CSS global ausgerichtet. Dies bedeutet, dass es sich nicht gut zum Bündeln eignet. Insbesondere das Bündeln zwischen mehreren Seiten, bei denen das Styling in einer CSS-Datei pro Seite getrennt ist und die Reihenfolge der Ladevorgänge von Bedeutung ist.

Nach unseren Messungen verwenden mehr als 50% der Next.js- Benutzer Webpack, um .css Dateien zu bündeln, entweder über @zeit/next-css , @zeit/next-sass , @zeit/next-less oder a benutzerdefinierte Installation. Dies wird durch Gespräche mit Unternehmen weiter überprüft. Einige haben alle ihre Stile durch Importieren von CSS, andere verwenden es für globale Stile und verwenden dann eine CSS-in-JS-Lösung, um Komponenten zu formatieren.

Derzeit haben wir diese drei Plugins, mit denen Sie CSS importieren können. Sie haben jedoch häufig Probleme bei der CSS-Bestellung und bestimmte Probleme beim Laden. Der Grund dafür ist, dass @zeit/next-css keine Konvention für globale Stile erzwingt. Globales CSS kann in jede Komponente / JavaScript-Datei im Projekt importiert werden.

Um diese häufigen Probleme zu lösen und Benutzern das Importieren von CSS zu erleichtern, planen wir die Einführung einer integrierten Unterstützung für CSS-Importe. Dies ähnelt styled-jsx. Wenn Sie die Funktion nicht verwenden, entsteht kein Erstellung oder Laufzeit.

Diese Bemühungen ermöglichen es uns auch, die Entwicklererfahrung mit der Lösung zu verbessern.

Vorschlag

Next.js sollte modernes CSS unterstützen und es im Namen des Benutzers herunterstufen. Dieser Ansatz ähnelt dem, wie wir modernes JavaScript unterstützen und es auf ES5 kompilieren.

Standardmäßig sollten wir:

Während der Entwicklung sollten CSS-Änderungen automatisch angewendet werden, ähnlich wie beim Hot-Reload von JavaScript.

In der Produktion sollte das gesamte CSS vollständig aus den JavaScript-Bundles .css -Dateien

Darüber hinaus sollte dieses .css (wenn möglich) in Code aufgeteilt werden, damit beim Laden der Seite nur das CSS für kritische Pfade heruntergeladen wird.

Globales CSS

Mit Next.js können Sie nur globales CSS innerhalb eines benutzerdefinierten pages/_app.js importieren.

Dies ist eine sehr wichtige Unterscheidung (und ein Konstruktionsfehler in anderen Frameworks), da das Importieren von globalem CSS an eine beliebige Stelle in Ihrer Anwendung bedeutet, dass aufgrund der Kaskadierung von CSS nichts in Code aufgeteilt werden kann.

Dies ist eine absichtliche Einschränkung. Denn wenn globales CSS beispielsweise in eine Komponente importiert wird, verhält es sich beim Wechsel von einer Seite zur anderen anders.

Anwendungsbeispiel

/* styles.css */
.red-text {
  color: red;
}
// pages/_app.js
import '../styles.css'

export default () => <p className="red-text">Hello, with red text!</p>

CSS auf Komponentenebene

Mit Next.js können reine CSS-Module überall in Ihrer Anwendung verwendet werden.

CSS auf Komponentenebene muss der Konvention entsprechen, die CSS-Datei .module.css zu benennen, um ihre Absicht anzuzeigen, mit der CSS-Modulspezifikation verwendet zu werden .

Der Bezeichner :global() CSS-Module ist zulässig, wenn er mit einem lokalen Klassennamen kombiniert wird, z. B. .foo :global(.bar) { ... } .

Anwendungsbeispiel

/* components/button.module.css */
.btnLarge {
  padding: 2rem 1rem;
  font-size: 1.25rem;
}

.foo :global(.bar) {
  /* this is allowed as an escape hatch */
  /* (useful when controlling 3rd party libraries) */
}

:global(.evil) {
  /* this is not allowed */
}
/* components/button.js */
import { btnLarge } from './button.module.css'

// import '../styles.css'; // <-- this would be an error

export function Button({ large = false, children }) {
  return (
    <button
      className={
        large
          ? // Imported from `button.module.css`: a unique class name (string).
            btnLarge
          : ''
      }
    >
      {children}
    </button>
  )
}

Hilfreichster Kommentar

Was auch immer wir hier tun, können wir sicherstellen, dass es immer noch einfach ist, benutzerdefinierte PostCSS-Plugins zu verwenden, wie es jetzt mit @zeit/next-css ? Es wäre eine echte Schande, wenn wir die Unterstützung dafür verlieren würden - CRA unterstützt dies nicht und aus diesem Grund ist es unmöglich, Tools wie Tailwind CSS auf irgendeine vernünftige Weise zu verwenden.

Ich würde in dieser Hinsicht vorsichtig mit diesen drei Merkmalen sein:

  • Verwenden Sie Autoprefixer, um herstellerspezifische Präfixe automatisch hinzuzufügen (ohne Unterstützung für ältere Flexboxen).
  • Polyfill oder kompilieren Sie Stage 3+ CSS-Funktionen mit ihren Entsprechungen
  • Beheben Sie automatisch bekannte "Flexbugs" für den Benutzer

... weil dies alles mit PostCSS erledigt wird und es sehr wichtig ist, dass die Reihenfolge der PostCSS-Plugins unter der Kontrolle des Endbenutzers liegt.

Ich würde vorschlagen, dass der Benutzer, wenn Sie diese drei Plugins standardmäßig aktivieren, die Standard-PostCSS-Konfiguration vollständig überschreiben kann, indem er seine eigene postcss.config.js -Datei bereitstellt. Sie müssten diese Plugins manuell hinzufügen, wenn sie diesen Weg gehen würden, aber diese Kontrolle ist meiner Meinung nach notwendig.

TL; DR Bitte achten Sie darauf, dass die Benutzer nicht die vollständige Kontrolle über PostCSS haben. Aus diesem Grund kann ich CRA buchstäblich nicht verwenden. Ich wäre sehr traurig, wenn ich Next nicht mehr verwenden könnte.

Alle 60 Kommentare

Ich vermute mit Plugins wie @zeit/next-sass bereits mit der aktuell unterstützten Version von CSS-Modulen arbeiten, dass .module.scss auch funktionieren würde? Oder bedeutet der Ausdruck "reine CSS-Module" nur .module.css ?

Sass Support ist es für die meisten Projekte für mich zu machen oder zu brechen.

Die Plugins @zeit/next-css/sass/less/stylus werden zugunsten dieses RFC (integrierte Unterstützung) nicht mehr unterstützt. Wir diskutieren immer noch, inwieweit Sass Teil des Kerns gegenüber einem Plugin sein wird. Mein aktuelles Denken ist, wenn Sie node-sass hinzufügen, wird die Sass-Unterstützung aktiviert. Ähnlich wie bei TypeScript. Der Grund, warum wir es nicht als Abhängigkeit hinzufügen, ist, dass es aufgrund nativer Bindungen usw. ziemlich groß und sehr langsam zu installieren ist.

Das ist spannend! Ich wurde wie heute von widersprüchlichen CSS-Klassennamen gestolpert!

Frage, wie funktioniert es mit TypeScript? Ein Grund, warum ich das CSS-Modul nicht aktiviert habe, ist, dass das Importieren des CSS-Moduls ein beliebiges Objekt ergeben würde (vielleicht wird ein bisschen magisch, wie .foo-bar wird ein Feld namens fooBar ?). Das ist nicht TS freundlich. Da Next jetzt standardmäßig TS ist, würde ich mir vorstellen, dass wir in dieser Angelegenheit besser abschneiden können?

Ich bin mir nicht sicher, ob "Bekannte Flexbugs für den Benutzer automatisch beheben" eine gute Idee ist.

Ich befürchte, dass wir in verwirrenden Szenarien enden werden, in denen sich Komponentenbibliotheken von Drittanbietern auf npm, die CSS-Stylesheets enthalten, in nextjs-Umgebungen anders verhalten als in anderen (z. B. create-react-app).

@TheHolyWaffle Das Beheben bekannter Flexbugs führt zu einem vorhersehbareren Verhalten - und genau das macht die Create React App.

@zenozen Gemäß der CSS- class-name ) verwenden, müssen Sie explizit auf diese im Objekt zugreifen.

z.B

import Everything from './file.module.css'

// later on

Everything['class-name']

Was TS betrifft, planen wir keine Magie, um mit den Typen umzugehen, aber es ist ziemlich einfach, einen TS-Typ zu definieren, der mit diesen Dateien umgeht.

declare module '*.module.css' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.scss' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.sass' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

Was auch immer wir hier tun, können wir sicherstellen, dass es immer noch einfach ist, benutzerdefinierte PostCSS-Plugins zu verwenden, wie es jetzt mit @zeit/next-css ? Es wäre eine echte Schande, wenn wir die Unterstützung dafür verlieren würden - CRA unterstützt dies nicht und aus diesem Grund ist es unmöglich, Tools wie Tailwind CSS auf irgendeine vernünftige Weise zu verwenden.

Ich würde in dieser Hinsicht vorsichtig mit diesen drei Merkmalen sein:

  • Verwenden Sie Autoprefixer, um herstellerspezifische Präfixe automatisch hinzuzufügen (ohne Unterstützung für ältere Flexboxen).
  • Polyfill oder kompilieren Sie Stage 3+ CSS-Funktionen mit ihren Entsprechungen
  • Beheben Sie automatisch bekannte "Flexbugs" für den Benutzer

... weil dies alles mit PostCSS erledigt wird und es sehr wichtig ist, dass die Reihenfolge der PostCSS-Plugins unter der Kontrolle des Endbenutzers liegt.

Ich würde vorschlagen, dass der Benutzer, wenn Sie diese drei Plugins standardmäßig aktivieren, die Standard-PostCSS-Konfiguration vollständig überschreiben kann, indem er seine eigene postcss.config.js -Datei bereitstellt. Sie müssten diese Plugins manuell hinzufügen, wenn sie diesen Weg gehen würden, aber diese Kontrolle ist meiner Meinung nach notwendig.

TL; DR Bitte achten Sie darauf, dass die Benutzer nicht die vollständige Kontrolle über PostCSS haben. Aus diesem Grund kann ich CRA buchstäblich nicht verwenden. Ich wäre sehr traurig, wenn ich Next nicht mehr verwenden könnte.

Seconding @adamwathan - wäre großartig, wenn Sie hier mehr darüber erfahren würden, wie die Anpassung der Post-CSS-Optionen aussehen würde. Es wäre wirklich großartig, eine Option zum Ändern der Postcss-Konfiguration über das nächste Plugin sowie über postcss.config.js , sodass Konfigurationen, die für mehrere Projekte freigegeben sind, problemlos ohne zusätzliche Datei eingefügt werden können.

Ich denke, dass es besser ist, CSS-Module für alle CSS-Importe zu aktivieren (nicht nur für das Suffix .module ), und für das, das wir global sein möchten, müssen wir ein Suffix .global angeben.

CSS-Module wären toll. Ich denke, die *.module.(css|scss) -Spezifikation beizubehalten ist in Ordnung, da sie mit create-react-app übereinstimmt, Typoskript-Typisierungen zulässt und anderen Benutzern, die neu bei Next.js sind, einfachere Migrationen ermöglicht

Mit Typoskript können Sie die Eingabe von CSS-Modulen erzwingen, indem Sie für jede *.(css|scss) -Datei mit typisierten CSS-Modulen und typisierten SCSS-Modulen *.d.ts Typisierungen generieren Wenn Sie weiterhin eine automatische Vervollständigung wünschen, können Sie die folgende VS-Code-Erweiterung verwenden:
https://marketplace.visualstudio.com/items?itemName=clinyong.vscode-css-modules

@adamwathan seien Sie versichert, dass wir die PostCSS-Konfiguration zulassen werden! Wir sind uns noch nicht sicher, wie die _exact_-Implementierung aussehen wird, aber sie sollte natürlich mit der CSS-Pull-Anforderung entstehen.

Das ist toll!! Gibt es dafür einen Zeitplan? Passiert es dieses Jahr?

@andreisoare Wir sind dabei, die globale Hälfte dieses RFC zusammenzuführen: https://github.com/zeit/next.js/pull/8710

Wir werden so schnell wie möglich mit der Unterstützung von CSS-Modulen fortfahren!

@adamwathan @Timer wäre großartig, wenn wir weiterhin die herkömmliche Datei postcss.config.js im Stammverzeichnis des Projekts verwenden könnten, wie wir es jetzt mit next-sass .

Ich bin so froh zu sehen, dass dies zum Kern kommt.

Wird das Rendern kritischer AMP-Pfade von diesem RFC unterstützt?

Wenn Sie können, sollten Sie für den Datensatz styled-jsx verwenden, da Sie damit CSS, HTML und JS in eine Idee, eine Komponente, einkapseln können. Wenn Sie dies noch nicht bemerkt haben (dies ist ein Hinweis für die Benutzer von next.js, nicht für die Betreuer), können Sie sich nicht in ein gesamtes CSS-UI-Kit wie Bootstrap einkaufen. Sie können 1 Komponente ausprobieren, und wenn dies nicht der Fall ist Sie passen nicht zu Ihren Anforderungen, sondern werfen es ohne die Last, mit dem Gepäck dieser externen CSS-Abhängigkeit umzugehen.

Ich denke, es ist auch sehr wichtig, dieses Wissen zu verbreiten, da CSS oft missverstanden oder nachträglich gedacht wird und oft zum Fluch einer Entwicklerarbeit wird. Aber mit der richtigen Abstraktion kann es tatsächlich recht einfach sein, darüber nachzudenken.

und nur weil "viele Leute" ihr CSS importieren, heißt das nicht, dass es eine großartige Idee ist.

Ich denke, eines der mächtigsten Dinge bei der Reaktion ist die Tatsache, dass es CSS, HTML und JS für Sie kapselt. und wenn Sie das CSS von der Seite laden (importieren), erhalten Sie einen Seitenschritt, der Ihnen Vorteile bringt.

Für den Datensatz: CSS-in-CSS (oder HTML) ist eine viel effizientere Transportschicht für Stile, und das Zusammenstellen von js und Stilen in einer Datei ist nicht besser als das Zusammenstellen in einem Verzeichnis.
Noch mehr: Der Großteil des CSS-in-JS der letzten Generation extrahiert CSS zum Zeitpunkt der Erstellung aus Gründen der Leistung in CSS. Daher ist eine ordnungsgemäße Verwaltung eines statischen CSS ein Muss. Die Art und Weise, wie solche Extraktionen von Next unterstützt würden, wurde jedoch noch nicht bekannt gegeben.

Für die Aufzeichnung: smile :: Mit SASS ist WENIGER mit einem Framework wie Bootstrap immer noch eine Sache und funktioniert wirklich großartig! Die Kapselung darf nicht auf JS-Ebene erfolgen. Die Verwendung von BEM ist eine Alternative. Die Unterstützung beider Wege ist unerlässlich.

@timer Bedeutet die erste Hälfte davon (https://github.com/zeit/next.js/pull/8710), dass die

(Siehe auch https://github.com/zeit/next-plugins/issues/190)

Globales CSS kann nicht auf Pfade aufgeteilt werden, also nein. Nur CSS-Module (auf Komponentenebene importiert) werden in den Pfad aufgeteilt. 👍

Gibt es eine Erklärung, wie sich dies auf die Probleme Nr. 9392 und Nr. 9385 auswirkt? Nur um zu verstehen, was hinter den Kulissen passiert. Damit konnte ich herausfinden, wie die Probleme in meiner Codebasis behoben werden können.

Hallo. Wir möchten unsere React-App auf next.js aktualisieren, um vor allem die großartigen Tools und das serverseitige Rendern zu nutzen.

Für uns ist es jedoch eine schwierige Voraussetzung, CSS-Module verwenden zu können. Wir haben es mit dem nächsten Plugin für CSS versucht, aber das hat das Chaos mit Problemen wie # 9392 # 9385 und mehr zunichte gemacht.

Gibt es eine ETA für die Unterstützung von CSS-Modulen (auch experimentell)? Gibt es eine Möglichkeit, die Entwicklung zu beschleunigen?

Wir können CSS also nicht auf Komponentenebene importieren?

Sie können, Sie müssen jetzt nur eine Problemumgehung verwenden, bis das Problem behoben ist. Ich denke, Sie können eine finden, die für Sie in der nächsten CSS-Ausgabe funktioniert.

Entschuldigung für die dumme Frage: Was das globale CSS betrifft, wie ist das anders / besser als nur einen Link in den Kopf aufzunehmen?

@otw Wenn Sie globales CSS importieren, durchläuft es die Build-Pipeline mit dem Rest Ihres Codes, sodass es minimiert wird usw. und wird dann Teil des Builds und der Ausgabe von next.js

Kommt auf dich an, wenn das von Vorteil ist. Ich kann mir vorstellen, dass sich die meisten Leute auf CSS-Module freuen, damit das für eine bestimmte Komponente benötigte CSS nur geladen wird, wenn die Komponente geladen wird.

Für den Kontext haben wir ein Team von Entwicklern, die NextJS in den letzten zwei Jahren verwendet haben, um fast 40 Webanwendungen für Startups im Frühstadium zu erstellen.

Ich möchte hier die Gelegenheit nutzen, um zu skizzieren, wie wir unsere Anwendungen so gestalten, dass sie aktuelle Anforderungen, Schwachstellen, Warnungen vor einigen erforderlichen npms und einige Bedenken hinsichtlich der vorgeschlagenen Änderungen anzeigen.

Aktuelle Implementierung

  • Wir unterhalten eine "Starter Kit" -Anwendung, in der ein Großteil unserer Kernfunktionen der App vorgefertigt ist. Es wird als Ausgangspunkt geklont, da es viele erweiterte Funktionen enthält, die nur aus der Verwendung von Bootstrap resultieren.
  • Wir verwenden Bootstrap und Reactstrap als Basis für unser Bootstrap-Richtlinien, um das Entwurfssystem zu erweitern und unsere eigenen Ergänzungen in Form zusätzlicher Konfigurationsoptionen, Mixins, Funktionen usw. einzubeziehen. Dies alles wird durch Importmuster in eine Sass-Datei implementiert global ohne CSS-Module über das Standard-Next-Sass-Beispiel von NextJS geladen. Screenshot: http://prntscr.com/qc8r0g.
  • Für viele unserer Projekte können wir das Styling hauptsächlich anhand der Dienstprogrammklassen erreichen, die von unserem erweiterten Bootstrap-Setup bereitgestellt werden. Es gibt jedoch Ausnahmen. Für diese Ausnahmen verwenden wir das SASS-Plugin mit styled-jsx . Der Grund, warum wir das SASS-Plugin verwenden, besteht darin, dass wir unsere Bootstrap-Variablen, -Funktionen und -Mixins aus unseren Globals importieren, um das Designsystem zusammenzuhalten. Wir haben einen speziellen Import namens "jsx-helper" gemacht, der diese in unser styled-jsx einbringt. Screenshot: http://prntscr.com/qc8xbr.
  • Bei einigen Layoutkomponenten, die die HTML-, Body- und Root-Div-Tags berühren müssen, bei einigen Plugins, die ein eigenes Markup generieren, oder bei NPMS, die Portale verwenden und CSS zum Berühren von Markups benötigen, auf die von der Komponente aus nicht zugegriffen werden kann, verwenden wir die globale Option styled -jsx. Dies ist ein letzter Ausweg, der jedoch für unsere Layoutkomponente erforderlich ist, wie Sie hier sehen können: http://prntscr.com/qc8yo6

Aktuelle Nachteile / Probleme

  • Wir würden lieber keinen injizierten SASS-Code (IDE-Probleme und mangelnde Unterstützung bei injizierten Sprachen) für unsere Komponenten verwenden, aber das Beispiel der Verwendung einer externen Sass-Datei mit styled-jsx funktioniert beim Importieren von Bootstrap-Variablen aufgrund eines bekannten Kompilierungsfehlers mit erforderlich nicht npm stylis . Das Projekt wird derzeit nicht unterstützt, daher würde ich dringend empfehlen, dass es nicht in einer von NextJS vorgeschlagenen Toolkette enthalten ist.
  • Änderungen an unseren globalen SCSS-Variablen, die in unseren styled-jsx SASS importiert wurden, werden nicht erkannt. Tatsächlich gibt es eine Art globalen npm-Modul-Cache, den wir nicht löschen können und der anscheinend dazu führt, dass Webpack Änderungen, die von unseren globalen Bootstrap-Variablen übertragen werden, nicht im laufenden Betrieb neu laden kann. Wenn Sie einen vollständigen npm ci ausführen, um den gesamten node_modules -Ordner neu zu erstellen, den Browser-Cache zu löschen, funktioniert der Befehl zum Löschen der Cache-Löschkraftkonsole nicht, da hier ein globaler npm-Cache vorhanden ist. Daher möchten wir, dass das Hot-Reload beim Aktualisieren von Dateien, die in CSS / SASS-Module importiert wurden, die auf Komponenten angewendet werden, ordnungsgemäß funktioniert. Kurz gesagt, jede von Komponenten durchgeführte SASS-Verarbeitung sollte auf Änderungen bei den Importen achten und das funktionierende Hot-Reloading aufrechterhalten. Dies wäre durch die im vorherigen Aufzählungspunkt angegebene Webpack Loader-Option behoben worden.
  • Wir mussten eine Lösung finden, um unsere PostCSS-Konfiguration an zwei verschiedenen Orten zu teilen, da globales SASS und styled-jsx getrennt erstellt werden.

Bedenken hinsichtlich vorgeschlagener Änderungen

Wir sind leicht besorgt über die Idee, die globale Option mit Komponenten-CSS / SASS-Modulen zu blockieren, da wir einige Anwendungsfälle haben, die basierend auf der Komponente die HTML-, Body- und Root-Div-Tags sowie Fälle von generiertem HTML berühren müssen Das ist in dieser Komponente aufgrund der Platzierung über Portale usw. nicht unbedingt vorhanden. Ich denke, wir könnten einiges davon mit globalem SASS und einigen Umstrukturierungen umgehen, sodass wir nicht darauf angewiesen sind, welche Komponente geladen wird, um bestimmtes globales CSS anzuwenden.

Wir wollen die volle Kontrolle über PostCSS und müssen uns lieber nicht damit auseinandersetzen, gezwungen zu sein, bestimmte Standardeinstellungen anzuwenden.

Entschuldigung, dies war eine lange Antwort, aber ich denke, wir hatten einige Erkenntnisse, die es wert waren, geteilt zu werden. Fühlen Sie sich frei, mich zu informieren, wenn Sie Fragen haben, und wir freuen uns darauf zu sehen, was die NextJS-Teams als nächstes einfallen lassen (Wortspiel beabsichtigt)!

@ Soundvessel ,

Wir sind leicht besorgt über die Idee, die globale Option mit Komponenten-CSS / SASS-Modulen zu blockieren, da wir einige Anwendungsfälle haben, die basierend auf der Komponente die HTML-, Body- und Root-Div-Tags sowie Fälle von generiertem HTML berühren müssen das ist in dieser Komponente nicht unbedingt vorhanden

Wenn ich Sie richtig verstanden habe, sollten Sie dies dennoch mit :global in CSS-Modulen erreichen können.

@ Daniellt1

Wenn ich Sie richtig verstanden habe, sollten Sie dies dennoch mit :global in CSS-Modulen erreichen können.

Siehe ihren Hinweis oben

Der Bezeichner für CSS-Module ist zulässig, wenn er mit einem lokalen Klassennamen kombiniert wird

Bei unserer Layoutkomponente zielen wir auf <html> , <body> und root div ohne lokalen Klassennamen.

In einem Video zu diesem Thema wurde auch erwähnt, dass sie erwägen, die Option :global vollständig zu blockieren, was für mich angesichts der großen Anzahl von npms- und CMS-APIs, die Markups generieren, die nicht berührt werden können, keinen Sinn ergibt von CSS-Modulen mit Gültigkeitsbereich.

Hey @Soundvessel - dies ist mein Video, das ich intern für mein Team aufgenommen habe (wie haben Sie Zugriff darauf erhalten?) Und das weder die Ansichten des nextjs-Teams direkt wiedergibt, noch aktuelle Informationen garantiert, seit es erstellt wurde in frühen experimentellen Stadien. Betrachten Sie den RFC als Kanon zu diesem Thema 😁

Ich möchte mich auch bei Ihnen dafür bedanken, dass Sie eine Lösung vorgeschlagen haben, die die Verwendung von CSS / SASS anstelle eines verschlungenen JS in einer CSS-Lösung ermöglicht, die zusätzliche Syntax wie camelCased-Eigenschaften usw. erfordert. Viele von uns kommen aus einem designorientierteren Bereich Hintergrund, jahrelange Erfahrung in der direkten Arbeit mit HTML / CSS, und es erleichtert uns, das, was wir im Code sehen, nicht zu tief in das zu übertragen, was wir auf dem Bildschirm debuggen.

Ich möchte nur hinzufügen, dass die automatische Erkennung / Aktivierung von Sass cool ist, es sei denn, ich habe oben eine Erwähnung verpasst, aber die Sass-API-Optionen müssen auch irgendwo verfügbar gemacht werden: [email protected] hat ein gutes Muster festgelegt, einschließlich des Zulassens des Benutzer kann wählen, welche Sass-Engine angewendet werden soll; ihre Optionen könnten 1: 1 übernommen werden ...

Ich möchte vorschlagen, dass die Erweiterung für CSS-Module konfigurierbar ist.
Möglicherweise ein Array verfügbar machen, um mehr als eine andere Erweiterung als .module.css ?
Das Erstellen einer .module.css -Datei und das Importieren dieser import "Component.module.css" wenn Sie für einige Entwickler viele Komponenten haben, scheint uns etwas aufgebläht zu sein.

In meinem Fall möchte ich in der Lage sein, eine Datei mit der Erweiterung .m.css zu erstellen, sagen Sie Component.m.css und importieren Sie sie als import "Component.m.css"

Es sei denn, das Next.js-Team gibt an, dass es einige technische Schwierigkeiten gibt, die dies verhindern.

Ich denke nicht, dass eine Konfiguration zum Benennen von Erweiterungen geöffnet werden sollte, da dies eine unnötige Erhöhung des Platzbedarfs zu sein scheint, aber ich frage die Notwendigkeit für die Erweiterung .module.css ob dies Teil der Implementierung sein wird:

Mit Next.js können Sie nur globales CSS innerhalb einer benutzerdefinierten Seite / _app.js importieren.

Anfangs dachte ich, .module.css wäre notwendig, damit der Build erkennt, was als CSS-Module analysiert werden soll und was nicht, aber wenn Nicht-Module in eine Komponente / Seite außerhalb von _app.js importiert werden Wenn ein Fehler auftritt und der Build unterbrochen wird, sollte die Namenskonvention nicht benötigt werden, da alles, was außerhalb von _app.js importiert wird, von Natur aus ein CSS-Modul sein sollte.

Wird dies eher als Konvention als als Notwendigkeit erzwungen?

Die Wahl der module.css -Konvention kollidiert mit der bereits von https://github.com/css-modules/css-modules festgelegten Konvention
Beispiele hier:
https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
und hier:
https://www.gatsbyjs.org/docs/css-modules/

Ja, wahrscheinlich kann die Konfiguration der Erweiterung die Komplexität mehr als erforderlich erschweren. Aber zumindest könnten Sie .module.css in einer konstanten Datei definieren und an mehreren Stellen nicht fest codiert sein, um sie durch Affen-Patches zu ändern

@bySabi

Der Unterschied zwischen dieser vorgeschlagenen Implementierung und create-react-app besteht darin, dass das Importieren eines "regulären Stylesheets" wie dem Beispiel, das Sie mit another-stylesheet.css verknüpft haben, überhaupt nicht zulässig ist. In diesem Fall wird .module.css verwendet, um zu bestimmen, welches Stylesheet von den Build-Tools auf welche Weise behandelt werden soll.

Die CSS-Modulspezifikation legt überhaupt keine Namenskonvention fest.

Ich weiß, dass CSS-Module keine Konvention über die Erweiterung der Dateien festlegen, sondern darüber, wie die Module importiert werden.

Ich möchte sagen, dass .module.css die von den Next.js-Teams gewählten Konventionen sind und sie die Möglichkeit "erleichtern" sollten, dass einige Benutzer sie ändern können, selbst wenn dies über ein Post-Installationsmodul erfolgt , das monkey patching ausführt

Ich denke, dass .module.css die erste Namenskonvention ist |

Die Wahl der module.css -Konvention kollidiert mit der Konvention, die bereits von css-modules / css-modules festgelegt wurde
Beispiele hier:
create-react-app.dev/docs/adding-a-css-modules-stylesheet
und hier:
gatsbyjs.org/docs/css-modules

Ja, wahrscheinlich kann die Konfiguration der Erweiterung die Komplexität mehr als erforderlich erschweren. Aber zumindest könnten Sie .module.css in einer konstanten Datei definieren und an mehreren Stellen nicht fest codiert sein, um sie durch Affen-Patches zu ändern

Sie widersprechen Ihrem Standpunkt hier: .module.css wird von create-react-app und gatsby für dieselbe Funktion verwendet. Es ist ein etabliertes Muster.

Das Ändern der Namenskonvention ist jedoch kein etabliertes Muster und es gibt keinen Grund, es in Next.js zuzulassen.

Ich denke, dass .module.css die erste Namenskonvention ist | Verlängerung von Next.Js. Bitte korrigieren Sie mich, wenn ich falsch liege.

Next.js legt Konventionen für Konfigurationsoptionen fest, z.

  • pages Verzeichnis sind Routen
  • pages/api sind API-Routen
  • Unterstützung für .js .tsx .tsx

Hallo @timneutkens

Das Muster besteht darin, wie CSS Modules festlegt, wie CSS-Dateien in JS-Objekte importiert werden sollen. Der Name des betreffenden CSS ist marginal. In dieser Hinsicht verwendet Next.js dieses spezielle Muster bei der neuen Implementierung nicht.
Die CSS Modules wie in Gatsby und CRA wurden bereits in Next implementiert: https://github.com/zeit/next-plugins/tree/master/packages/next-css

Ich stelle die verwendete Konvention .module.css nicht in Frage, auch wenn ich weiß, dass ich CRA- und Gatsby-Benutzer mit CSS Modules verwechseln könnte. Die Wahl eines geeigneten Namens ist schwierig und nicht jeder ist immer glücklich.

Obwohl ich glaube, dass die .m.css -Konvention besser ist, weil sie kürzer (besser für eine Erweiterung geeignet) und weniger redundant (import-Anweisung ist für den Import von Modulen) ist, möchte ich, dass Sie dies berücksichtigen. Das Definieren von Konventionen im Allgemeinen und von .module.css im Besonderen in einer konstanten Datei würde ausreichen, um sie zu patchen.

Trotzdem herzlichen Glückwunsch zu den CSS-Modulen. Sie haben großartige Arbeit geleistet, es schien eine "fast" unmögliche Aufgabe zu sein.

Wenn ich meine zwei Cent für die Namenskonvention hinzufügen kann: Wir haben eine Komponentenbibliothek, die die Erweiterung .pcss da wir PostCSS zum Kompilieren benötigen, und wir haben uns für diese Namenskonvention entschieden. Außerdem müssen wir diese CSS als Modul importieren . Wie würden Sie diesen Fall angehen? Wir hacken derzeit die Webpack-Konfiguration und patchen den Test-Regex der Loader, aber es fühlt sich schmutzig an, wie Sie sich vorstellen können.

Ich stelle mir vor, dass .module.css postCSS genauso unterstützt wie globale .css derzeit.

Ich weiß was passiert, ich glaube ich brauche Urlaub.

Bei der Überprüfung der PR: https://github.com/zeit/next.js/pull/9686 dachte ich, ich hätte "gesehen", dass CSS-Module genauso wie globale Module importiert wurden.

Ich dachte aufrichtig, ich hätte diesen Code gelesen:

index.module.css

.redText {
  color: net;
}
import './index.module.css'

export default function Home () {
  return (
    <div id = "verify-red" className = "redText">
      This text should be red.
    </div>
  )
}

Offensichtlich nichts mit der Realität zu tun. In Wirklichkeit ist dies der wahre Code.

import {redText} from './index.module.css'

export default function Home () {
  return (
    <div id = "verify-red" className = {redText}>
      This text should be red.
    </div>
  )
}

Nur CSS-Module wie in CRA oder Gatsby. Daher die Verwirrung, meine Verwirrung.

Ich entschuldige mich bei allen für den Fehler.

:-(

Bei Verwendung von CSS-Modulen besteht das Hauptproblem darin, dass:

Verwenden Sie in meinem Projekt CSS-Module, und einige Komponenten von Drittanbietern verwenden auch CSS-Module.
Aber ... einige Komponenten von Drittanbietern verwenden globales CSS.

Ich denke, die Lösung der Erweiterung .module.css ist leicht zu verstehen und zu implementieren.
Und die anderen Frameworks (CRA 、 Gatsby) haben einen Konsens erreicht.

Bisher habe ich keine Probleme mit der Erweiterungslösung festgestellt.
Ich hoffe also, die Entwicklung der Erweiterung .module.css fördern.

Wenn es eine andere Lösung für das Problem der CSS-Module gibt, ist es besser.

@bySabi
.m.css ist zwar kürzer, aber ich denke nicht, dass es besser ist.
Ist es min.css oder module.css ?

@ xyy94813 oder genau das Gegenteil, alle CSS-Importe sind Module, Dateien mit .global.scss sind globale Dateien

@felixmosh
Es ist jedoch unfreundlich, Komponenten zu veröffentlichen.

Ich denke, die Konvention ist eine gute Standardeinstellung, aber dass einige Konfigurationsoptionen, die für CSS-Module spezifisch sind, irgendwann verfügbar gemacht werden sollten, zum Beispiel diejenigen, die an css-loader , da einige Benutzer die Kontrolle über den "Umfang" wünschen. Klassennamen werden ausgegeben. Eine Option könnte hinzugefügt werden, um einen regulären Ausdruck bereitzustellen, der bestimmt, welche CSS-Dateien als "Module" geladen werden.

Einige Benutzer möchten die Kontrolle darüber haben, wie die Klassennamen mit Gültigkeitsbereich ausgegeben werden

Beispiele, warum Sie das wollen? Mir fällt nichts ein.

Beispiele, wenn Sie das wollen? Mir fällt nichts ein.

@timneutkens Nun, ich würde es vielleicht vorziehen, ein
Darüber hinaus dachte ich an Szenarien zum Löschen oder Aufteilen oder Laden nach dem Erstellen, in denen ich möglicherweise einen bestimmten Namespace auf die Whitelist setzen möchte, aber das habe ich noch nicht herausgefunden

Ich denke, es ist wichtig, sich daran zu erinnern, dass ein Rahmen mit Meinungen dazu gedacht ist, Entscheidungen für Sie zu treffen, um die anfängliche Einrichtung zu vermeiden und die Einheitlichkeit durchzusetzen.

Einige dieser Entscheidungen sollten Standardeinstellungen enthalten, die durch Konfigurationsoptionen oder Erweiterungen geändert werden können. Mit allem, was Sie anpassbar machen, erhöhen Sie jedoch die Codebasis, wodurch mehr Code zum Testen, Verwalten und Dokumentieren erstellt wird, der wiederum beibehalten werden muss.

Etwas wie das Hash-Muster für die Ausgabe mit Gültigkeitsbereich ist so detailliert, wenn Sie an einem Punkt angelangt sind, an dem Sie den Standard überschreiben müssen. Wahrscheinlich befinden Sie sich an dem Punkt, an dem Sie nur den benutzerdefinierten Loader schreiben sollten, den Sie selbst benötigen.

Bei der Arbeit mit neuen React-Entwicklern war es für mich immer viel einfacher, das Konzept der Scoping-Stile über className auf eine Komponente zu übertragen. Geben Sie dem äußeren Element in Ihrer Komponente einfach einen eindeutigen Klassennamen, der normalerweise mit Ihrem Komponentennamen identisch ist, und schreiben Sie Ihren Stil wie folgt, wenn Sie SCSS verwenden:

.Navbar {
  .logo { ... }
  .nav-item { ... }
}

Ich sehe definitiv die Vorteile von css-modules , aber ich mache mir ein bisschen Sorgen, dass Next.js, wenn die oben genannte Methode nicht mehr unterstützt wird, weniger freundlich zu neuen Entwicklern wird. Vielleicht ist das ein guter Kompromiss, wenn Sie sehen, dass viele Leute auf Probleme mit der CSS-Bestellung stoßen, aber ich frage mich, ob die Durchsetzung von css-modules zumindest über next.config.js deaktiviert werden könnte. Oder vielleicht könnten wir sogar eine Überprüfung der Erstellungszeit durchführen lassen, die sicherstellt, dass alle Stile ordnungsgemäß mit einem eindeutigen Klassennamen versehen sind, obwohl nicht sicher ist, wie machbar das technisch ist.

Ich mache mir ein bisschen Sorgen, dass Next.js weniger freundlich zu neuen Entwicklern wird, wenn die oben genannte Methode nicht mehr unterstützt wird

Sofern ich nichts falsch verstanden habe, denke ich nicht, dass die Sache mit den CSS-Modulen exklusiv ist, sondern dass der Loader den Parser der CSS-Module nur anwenden würde, wenn die von Ihnen importierte Datei das Namensmuster *.module.css oder *.module.scss für diese Angelegenheit

@ lunelson-bl

Es ist semi-exklusiv im Gegensatz dazu, wie CRA oder Gatsby den Parser nur aktivieren, wenn Sie das Namensmuster verwenden. Next würde den Import von Nicht-Modulen direkt in die Komponente JS nicht zulassen.

Aus dem RFC:

/* components/button.js */
import { btnLarge } from './button.module.css'

// import '../styles.css'; // <-- this would be an error

Um Klassen zu verwenden, die keine Module sind, müssen Sie das Stylesheet in Ihr globales Stylesheet importieren, das nur in _app.js importiert wird (wenn Sie möchten, dass sie mit Ihren Komponentendateien geteilt und kolokalisiert werden). Andernfalls müssten sie direkt in das globale Stylesheet eingefügt werden.

Ich bin ein neuer Benutzer von next.js. Nachdem ich diese Ausgabe gelesen habe und mich ein wenig verwirrt fühle. Ich denke, wenn die next.js Build-in-CSS-Unterstützung unterstützen , brauchen wir kein @ next-CSS-Plugin, aber es funktioniert nicht und wirft einen Fehler über "ModuleParseError".
Wenn ich das @ next-css-Plugin hinzufüge, um Unterstützung für CSS-Importe hinzuzufügen, funktioniert es. Wie können Sie also ein Beispiel bereitstellen, wenn Sie die integrierte CSS-Unterstützung ohne @ next-css unterstützen?
danke @all.

Ich bin ein neuer Benutzer von next.js. Nachdem ich diese Ausgabe gelesen habe, bin ich etwas verwirrt. Ich denke, next.js unterstützt Build- CSS
Wenn ich es zum @ next-css-Plugin hinzufüge, um CSS-Importunterstützung hinzuzufügen, funktioniert es. Wie können Sie also ein css-Build ohne @ next-css erstellen? Können Sie ein Beispiel geben?
danke @ALL .

Fügen Sie Ihrer next.config.js eine Konfiguration wie folgt hinzu:

module.exports = {
  experimental: {
    css: true
  }
}

@erkanunluturk danke, es ist in
Und wie ist es mit antd kompatibel? Ich weiß, dass With-Ant-Design in Ordnung ist.

@Timer Können Sie ein Beispiel für die

Ich habe immer noch ein Problem mit Router.push ("/"), wenn ich mich in einem anderen Link befinde. Hat jemand eine Lösung dafür? Bitte helfen Sie mir, vielen Dank

: Warnung: Bitte verwenden Sie diesen Thread nicht mehr als Wunsch und geben Sie den Tracker aus. Dies ist ein RFC und sie implementieren ihn noch.

Der letzte aussagekräftige Kommentar des Teams lautet https://github.com/zeit/next.js/issues/8626#issuecomment -531415968. Sie können die aktuelle Implementierung bewerten, indem Sie sie über https://github.com/zeit/next aktivieren

Ich vermisse die Möglichkeit, die Arbeit zu verfolgen. Wie können wir helfen? @Timer ist es möglich, diesen RFC mit Meilensteinen, einer Roadmap, zu verbinden? Was wird aus den Punkten im RFC gemacht?

Keine Ahnung, wie man den Überblick behält: verwirrt:

@StarpTech dieser RFC ist vollständig implementiert; Globale CSS- und CSS-Module funktionieren gemäß der RFC-Beschreibung.

Sie können beide mit der einzigen experimentellen Flagge testen!

Ich werde diesen Thread sperren, um eine weitere Ausbreitung von Benachrichtigungen zu verhindern. Wenn jemand Probleme identifiziert, öffnen Sie bitte ein neues Problem und lassen Sie es uns wissen! Wir werden hier posten, wenn der Support offiziell als stabil markiert ist (und standardmäßig aktiviert ist).

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen