Next.js: [RFC] Prise en charge CSS

Je suppose qu'avec des plugins comme @zeit/next-sass fonctionnant déjà avec la version actuellement prise en charge des modules CSS, .module.scss fonctionnerait également? Ou est-ce que l'expression «modules CSS purs» signifie seulement .module.css ?

Pour moi, le soutien de Sass est de réussir ou de le casser pour la plupart des projets.

Les plugins @zeit/next-css/sass/less/stylus seront obsolètes au profit de cette RFC (support intégré). Nous discutons toujours de la mesure dans laquelle sass fera partie du noyau par rapport à un plugin. Ma réflexion actuelle est que lorsque vous ajoutez node-sass cela activera le support sass. Similaire à ce que nous faisons pour TypeScript. La raison pour laquelle nous ne l'ajouterons pas en tant que dépendance est qu'elle est assez volumineuse et très lente à installer en raison des liaisons natives, etc.

C'est excitant! J'ai été trébuché par des noms de classes css contradictoires comme aujourd'hui!

Question, comment ça marche avec TypeScript? Une des raisons pour lesquelles je n'ai pas activé le module css est que l'importation d'un module css donnerait n'importe quel objet (peut-être un peu magique, comme .foo-bar deviendra un champ appelé fooBar ?), ce qui n'est pas convivial TS. Puisque Next est maintenant TS par défaut, j'imagine que nous pouvons faire mieux dans ce domaine?

Je ne suis pas sûr que "Réparer automatiquement les bogues flexibles connus pour l'utilisateur" soit une bonne idée.

Je crains que nous ne finissions dans des scénarios confus où les bibliothèques de composants tiers sur npm, qui incluent des feuilles de style css, se comportent différemment dans les environnements nextjs que dans d'autres (comme create-react-app).

@TheHolyWaffle corrigeant les

@zenozen Selon les spécifications des modules CSS, il ne fait rien d'extraordinaire à camelcase pour vous. Si vous utilisez des noms de classe avec un tiret ( class-name ), vous devez y accéder explicitement sur l'objet.

par exemple

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

// later on

Everything['class-name']

En ce qui concerne TS, nous ne prévoyons aucune magie pour gérer les types mais il est assez facile de définir un type TS pour gérer ces fichiers.

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;
}

Quoi que nous fassions ici, pouvons-nous nous assurer qu'il est toujours facile d'utiliser des plugins PostCSS personnalisés comme c'est le cas maintenant avec @zeit/next-css ? Ce serait vraiment dommage si nous perdions le support pour cela - l'ARC ne le supporte pas et à cause de cela, il est impossible d'utiliser des outils comme Tailwind CSS de quelque manière que ce soit.

Je ferais attention à ces trois caractéristiques à cet égard:

• Utilisez Autoprefixer pour ajouter automatiquement des préfixes spécifiques au fournisseur (sans prise en charge de la flexbox héritée)
• Polyfill ou compilez les fonctionnalités CSS Stage 3+ avec leurs équivalents
• Correction automatique des "flexbugs" connus pour l'utilisateur

... parce que tout cela est fait avec PostCSS, et il est très important que l'ordre des plugins PostCSS soit sous le contrôle de l'utilisateur final.

Je suggérerais que si vous allez activer ces trois plugins par défaut, l'utilisateur devrait être en mesure de remplacer complètement la configuration PostCSS par défaut en fournissant son propre fichier postcss.config.js . Ils devraient ajouter ces plugins manuellement s'ils empruntaient cette voie, mais ce niveau de contrôle est nécessaire à mon avis.

TL; DR veillez à ne pas interrompre la capacité des utilisateurs à avoir un contrôle complet de PostCSS, je ne peux littéralement pas utiliser CRA à cause de cela et je serais très triste si je ne pouvais plus utiliser Next.

Soutenir @adamwathan - serait bien d'avoir plus de détails ici sur l'apparence de la personnalisation des options postcss. Ce serait vraiment génial d'avoir une option pour modifier la configuration postcss via le prochain plugin ainsi que postcss.config.js , afin que les configurations partagées entre plusieurs projets puissent être facilement injectées sans fichier supplémentaire.

Je pense qu'il est préférable d'activer les modules css pour toutes les importations css (pas seulement pour le suffixe .module ), et celui que nous voulons être global, nous devrons spécifier un suffixe .global .

Les modules CSS seraient super. Je pense que garder la spécification *.module.(css|scss) est bien car il s'aligne avec create-react-app , permet des typages dactylographiés et permet des migrations plus faciles pour les autres utilisateurs nouveaux sur Next.js

Avec tapuscrit, vous pouvez appliquer typages du module CSS en générant *.d.ts typages pour chaque *.(css|scss) fichier en utilisant des modules-css-dactylographiées et modules-SCSS typé mais si vous ne voulez pas faire et veulent toujours la saisie semi-automatique, vous pouvez utiliser l'extension VS Code suivante:
https://marketplace.visualstudio.com/items?itemName=clinyong.vscode-css-modules

@adamwathan soyez assuré que nous autoriserons la configuration PostCSS! Nous ne savons pas encore à quoi ressemblera l'implémentation _exact_, mais elle devrait apparaître naturellement avec la pull request CSS.

C'est bien!! Y a-t-il un calendrier pour cela? Cela se passe-t-il cette année?

@andreisoare, nous sommes sur le point de fusionner la moitié mondiale de cette RFC: https://github.com/zeit/next.js/pull/8710

Nous allons continuer sur le support des modules CSS dès que possible!

@adamwathan @Timer serait génial si nous pouvions continuer à utiliser le fichier postcss.config.js conventionnel à la racine du projet, comme nous pouvons maintenant avec next-sass .

Je suis si heureux de voir cela venir au cœur.

Le rendu du chemin critique AMP sera-t-il pris en charge par cette RFC?

pour mémoire, si vous le pouvez, vous devriez utiliser styled-jsx car il vous permet d'encapsuler css, html et js en une seule idée, un composant. Si vous ne l'avez pas déjà réalisé (ceci est une note aux utilisateurs de next.js et non aux responsables), cela vous permet de ne pas avoir à acheter dans un kit d'interface utilisateur CSS entier comme bootstrap, vous pouvez essayer 1 composant et si ce n'est pas le cas ne répond pas à vos besoins, vous le jetez sans avoir à gérer le bagage de cette dépendance CSS externe.

Je pense qu'il est également très important de diffuser ces connaissances car CSS est souvent mal compris ou après coup et devient souvent le fléau du travail d'un développeur. Mais avec une abstraction appropriée, il peut en fait être assez facile de raisonner.

et ce n'est pas parce que "beaucoup de gens" importent leur CSS que c'est une excellente idée.

Je pense que l'une des choses les plus puissantes de react est le fait qu'il encapsule CSS, HTML et JS pour vous. et si vous chargez (importez) le CSS de côté, vous êtes en quelque sorte le pas de côté que vous offre React.

Pour mémoire: CSS-in-CSS (ou HTML) est une couche de transport beaucoup plus efficace pour les styles, et colocaliser les js et les styles dans un seul fichier n'est pas mieux que de les colocaliser dans un répertoire.
Encore plus - la majorité de la dernière génération de CSS-in-JS extrait le CSS en CSS au moment de la construction pour des raisons de performances, donc une bonne gestion d'un CSS statique est indispensable. Cependant, la manière dont ces extractions seraient prises en charge par Next n'a pas encore été divulguée.

Pour mémoire: smile :: Utiliser SASS, LESS avec un Framework comme Bootstrap est toujours une chose et fonctionne vraiment très bien! L'encapsulation ne doit pas se produire au niveau JS. L'utilisation de BEM est une alternative. Soutenir dans les deux sens est essentiel.

@timer La première moitié de ceci (https://github.com/zeit/next.js/pull/8710) signifie-t-elle que le partage de chemin de CSS fonctionne maintenant? Ou est-ce encore à venir?

(En relation, https://github.com/zeit/next-plugins/issues/190)

Le CSS global ne peut pas être divisé par chemin, donc non. Seuls les modules CSS (importés au niveau du composant) seront divisés par chemin. 👍

Y a-t-il une explication sur la façon dont cela affecte les problèmes # 9392 et # 9385? Juste pour comprendre ce qui se passe dans les coulisses. Pour cela, je pourrais travailler sur la façon de résoudre les problèmes sur ma base de code.

Salut. Nous cherchons à mettre à niveau notre application React vers next.js principalement pour profiter des excellents outils et du rendu côté serveur.

Cependant, pour nous, il est difficile de pouvoir utiliser les modules CSS. Nous avons essayé avec le prochain plugin pour CSS, mais cela a fait des ravages avec des problèmes comme # 9392 # 9385 et plus.

Existe-t-il un ETA pour le support des modules CSS (même expérimental)? Un moyen de contribuer à accélérer son développement?

Nous ne pouvons donc pas importer du CSS au niveau des composants?

Vous pouvez, il vous suffit d'utiliser une solution de contournement dès maintenant jusqu'à ce que le problème soit résolu. Je pense que vous pouvez en trouver un qui fonctionne pour vous sur le prochain numéro css .

Désolé pour la question stupide: en ce qui concerne le CSS global, en quoi est-ce différent / meilleur que d'inclure simplement un lien dans la tête?

@otw si vous importez du CSS global, il passe par le pipeline de construction avec le reste de votre code afin qu'il soit minimisé, etc. devient alors partie de la construction et de la sortie de next.js

Cela dépend de vous si c'est un avantage. J'imagine que la plupart des gens attendent avec impatience les modules CSS afin que le CSS nécessaire pour un composant spécifique ne soit chargé que lorsque le composant est chargé.

Pour le contexte, nous avons une équipe de développeurs qui ont utilisé NextJS au cours des deux dernières années pour créer près de 40 applications Web pour les startups en démarrage.

Je veux profiter de l'occasion ici pour décrire comment nous stylisons nos applications pour montrer les besoins actuels, les points faibles, les avertissements concernant certains npms requis auxquels nous avons été confrontés et certaines préoccupations concernant les changements proposés.

Mise en œuvre actuelle

• Nous maintenons une application "kit de démarrage" qui a une grande partie de nos fonctionnalités de base pré-construites. Il est cloné comme point de départ car il contient de nombreuses fonctionnalités étendues provenant de l'utilisation de Bootstrap.
• Nous utilisons Bootstrap et Reactstrap comme base de notre système de conception. Parce que nous voulons un système de conception cohérent, nous utilisons le SASS global avec les directives de Bootstrap pour étendre le système de conception et incorporer nos propres ajouts sous la forme d'options de configuration supplémentaires, de mixins, de fonctions, etc. chargé globalement sans modules css via l'exemple standard next-sass de NextJS. Capture d'écran: http://prntscr.com/qc8r0g.
• Pour la plupart de nos projets, nous pouvons obtenir un style principalement via les classes utilitaires fournies par notre configuration Bootstrap étendue, mais il existe des exceptions. Pour ces exceptions, nous utilisons le plugin SASS avec styled-jsx . La raison pour laquelle nous utilisons le plugin SASS est que nous importons nos variables, fonctions et mixins de bootstrap de nos globals pour garder le système de conception cohérent. Nous avons fait une importation spéciale appelée "jsx-helper" qui les introduit dans notre styled-jsx. Capture d'écran: http://prntscr.com/qc8xbr.
• Dans le cas de certains composants de mise en page qui doivent toucher les balises html, body et root div, certains plugins qui génèrent leur propre balisage, ou npms qui utilisent des portails et ont besoin de CSS pour toucher le balisage non accessible à partir du composant, nous utilisons l'option globale styled -jsx. Ceci est un dernier recours mais nécessaire pour notre composant de mise en page comme vous pouvez le voir ici: http://prntscr.com/qc8yo6

Inconvénients / problèmes actuels

• Nous préférerions ne pas utiliser de code SASS injecté (problèmes IDE et manque de support avec les langages injectés) avec nos composants mais l' exemple d'utilisation d'un fichier sass externe avec styled-jsx ne fonctionne pas lors de l'importation de variables d'amorçage en raison d'un bug de compilation connu avec requis npm stylis . Le projet ne semble pas pris en charge à ce stade, je recommande donc fortement qu'il ne fasse partie d'aucune chaîne d'outils proposée par NextJS.
• Les modifications apportées à nos variables SCSS globales importées dans notre SASS styled-jsx ne sont pas détectées. En fait, il existe une sorte de cache de module global npm que nous ne pouvons pas effacer et qui semble empêcher Webpack de recharger à chaud les modifications qui se propagent à partir de nos variables globales Bootstrap. Faire un npm ci complet pour reconstruire tout le dossier node_modules , effacer le cache du navigateur, la commande cache clear force console ne fonctionne pas car il y a un cache global npm comme travail ici. Par conséquent, nous aimerions beaucoup que le rechargement à chaud fonctionne correctement lors de la mise à jour des fichiers importés dans les modules CSS / SASS appliqués aux composants. En bref, tout traitement SASS effectué par les composants doit surveiller les modifications apportées aux importations et maintenir un rechargement à chaud fonctionnel. Cela aurait été résolu par l'option de chargement du pack Web indiquée dans la puce précédente.
• Nous avons dû trouver une solution pour partager notre configuration PostCSS en deux endroits distincts, car SASS global et styled-jsx sont construits séparément.

Préoccupations concernant les changements proposés

Nous sommes légèrement préoccupés par l'idée de bloquer l'option globale avec les modules CSS / SASS du composant car nous avons des cas d'utilisation qui doivent, en fonction du composant, toucher les balises div html, body et root ainsi que des cas de HTML généré cela n'existe pas nécessairement à l'intérieur dudit composant en raison du placement via des portails, etc. Je pense que nous pourrions contourner ce problème avec le SASS global et une certaine restructuration afin que nous ne dépendions pas du composant chargé pour appliquer un CSS global spécifique.

Nous voulons un contrôle total sur PostCSS et préférerions ne pas être obligés d'appliquer un ensemble spécifique de valeurs par défaut.

Désolé, cette réponse a été longue, mais je pense que nous avons eu quelques idées qui méritent d'être partagées. N'hésitez pas à me faire savoir si vous avez des questions et nous sommes impatients de voir ce que les équipes NextJS proposeront ensuite (jeu de mots)!

@Soundvessel ,

Nous sommes légèrement préoccupés par l'idée de bloquer l'option globale avec les modules CSS / SASS du composant car nous avons des cas d'utilisation qui doivent, en fonction du composant, toucher les balises div html, body et root ainsi que des cas de HTML généré qui n'existe pas nécessairement à l'intérieur dudit composant

Si je vous ai bien compris, vous devriez toujours pouvoir y parvenir en utilisant :global dans les modules CSS.

@ Daniellt1

Si je vous ai bien compris, vous devriez toujours pouvoir y parvenir en utilisant :global dans les modules CSS.

Voir leur note ci-dessus

Le spécificateur de modules CSS est autorisé lorsqu'il est combiné avec un nom de classe local

Dans le cas de notre composant de mise en page, nous ciblons <html> , <body> et div racine sans nom de classe locale.

Il a également été mentionné dans une vidéo sur ce sujet qu'ils envisageaient de bloquer complètement l'option :global , ce qui n'a aucun sens pour moi compte tenu du grand nombre de npms et d'API CMS qui génèrent un balisage qui ne peut pas être touché. par des modules css étendus.

Hey @Soundvessel - c'est ma vidéo que j'ai enregistrée en interne pour mon équipe (comment y avez-vous eu accès?), Et ne représente pas directement les vues de l'équipe nextjs, ni ne garantit des informations à jour depuis sa création au cours des premières étapes expérimentales. Considérez la RFC comme un canon sur ce sujet 😁

Je voudrais également vous remercier d'avoir proposé une solution qui permet l'utilisation de CSS / SASS plutôt qu'une solution JS alambiquée dans CSS qui nécessite une syntaxe supplémentaire telle que les propriétés camelCased etc. Nous sommes nombreux à venir d'un plus axé sur le design background, ayant des années d'expérience de travail directement avec HTML / CSS, et cela nous permet de ne pas avoir à transposer trop profondément ce que nous voyons dans le code dans ce que nous débogage à l'écran.

Je veux juste ajouter, sauf si j'ai manqué une mention ci-dessus, que la détection automatique / l'activation de Sass est cool, mais les options de l'API Sass doivent également être exposées quelque part: [email protected] a établi un bon modèle, y compris l'autorisation de l'utilisateur doit choisir quel moteur sass appliquer; leurs options pourraient être prises en charge 1: 1 ...

Je voudrais proposer que l'extension pour les modules CSS soit configurable.
Peut-être exposer un tableau pour prendre en charge plus d'une extension autre que .module.css ?
Créer un fichier .module.css et l'importer import "Component.module.css" lorsque vous avez beaucoup de composants pour certains développeurs nous semble un peu gonflé.

Dans mon cas, je voudrais pouvoir créer un fichier avec l'extension: .m.css , dites Component.m.css et importez-le comme import "Component.m.css"

À moins que l'équipe Next.js ne dise qu'il y a des difficultés techniques qui empêchent cela de se faire.

Je ne pense pas qu'une configuration pour nommer les extensions devrait être ouverte car cela semble être une augmentation inutile de l'empreinte, mais je remets en question le _need_ pour l'extension .module.css si cela fera partie de l'implémentation:

Next.js ne vous permettra d'importer Global CSS que dans une page personnalisée / _app.js.

J'ai d'abord pensé que .module.css serait nécessaire pour que la construction détecte ce qui devrait être analysé en tant que modules CSS et ce qui ne devrait pas l'être, mais si vous importez des non-modules dans un composant / une page en dehors de _app.js se produira une erreur et interrompra la construction, la convention de dénomination ne devrait pas être nécessaire car tout ce qui est importé en dehors de _app.js devrait être un module CSS par nature.

Est-ce que cela est imposé uniquement par convention plutôt que par nécessité?

Le choix de la convention module.css heurte au couvent déjà établi par https://github.com/css-modules/css-modules
Exemples ici:
https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
et ici:
https://www.gatsbyjs.org/docs/css-modules/

Oui, rendre l'extension configurable pourrait probablement la compliquer plus que nécessaire. Mais au moins, vous pouvez définir .module.css dans un fichier constant et non codé en dur à plusieurs endroits pour le changer via monkey patching

@bySabi

La différence entre cette implémentation proposée et create-react-app est que l'importation d'une "feuille de style standard" comme l'exemple que vous avez lié avec another-stylesheet.css ne serait pas du tout autorisée. Dans ce cas, .module.css est utilisé pour déterminer quelle feuille de style doit être gérée de quelle manière par les outils de construction.

La spécification des modules CSS n'établit pas du tout de convention de dénomination.

Je sais que les modules CSS n'établissent aucune convention sur l'extension des fichiers mais sur la manière dont les modules sont importés.

Là où je veux aller, c'est que .module.css sont les conventions choisies par les équipes Next.js et qu'elles devraient "faciliter" la possibilité que certains utilisateurs puissent le changer même si c'est via un module post-installation qui fait monkey patching

Je pense que .module.css est la première convention de dénomination |

Le choix de la convention module.css heurte au couvent déjà établi par css-modules / css-modules
Exemples ici:
create-react-app.dev/docs/adding-a-css-modules-stylesheet
et ici:
gatsbyjs.org/docs/css-modules

Oui, rendre l'extension configurable pourrait probablement la compliquer plus que nécessaire. Mais au moins, vous pouvez définir .module.css dans un fichier constant et non codé en dur à plusieurs endroits pour le changer via monkey patching

Vous contredisez votre point ici, .module.css est utilisé par create-react-app et gatsby pour la même fonctionnalité. C'est un modèle établi.

changer la convention de dénomination n'est cependant pas un modèle établi et il n'y a aucune raison de l'autoriser dans Next.js.

Je pense que .module.css est la première convention de dénomination | extension imposée par Next.Js. Corrigez-moi si j'ai tort, s'il-vous plait.

Next.js établit des conventions sur les options de configuration, par exemple:

• pages répertoire étant des routes
• pages/api étant des routes API
• support pour .js .tsx .tsx

Salut @timneutkens

Le modèle est dans la façon dont CSS Modules établit comment les fichiers CSS doivent être importés dans des objets JS, le nom du CSS en question est marginal. À cet égard, Next.js n'utilise pas ce modèle particulier avec la nouvelle implémentation.
Les CSS Modules comme dans Gatsby et CRA étaient déjà implémentés dans Next avant: https://github.com/zeit/next-plugins/tree/master/packages/next-css

Je ne remets pas en question la convention utilisée, .module.css , même en sachant que je pourrais confondre les utilisateurs de l'ARC et de Gatsby avec CSS Modules . Choisir un nom approprié est difficile et tout le monde n'est pas toujours content.

Bien que je pense que la convention .m.css est meilleure car elle est plus courte (plus appropriée pour une extension) et moins redondante (la déclaration d'importation est pour l'importation de modules), j'aimerais que vous en teniez compte. Définir les conventions en général et .module.css en particulier dans un fichier constant aiderait suffisamment à les corriger.

Quoi qu'il en soit, bravo pour les modules CSS. Vous avez fait un travail magnifique, cela semblait une tâche "presque" impossible.

Si je peux ajouter mes deux cents sur la convention de nommage: nous avons une bibliothèque de composants qui utilise l'extension .pcss car nous avons besoin de PostCSS pour la compilation et nous avons décidé d'utiliser cette convention de nommage, nous devons également importer ces CSS en tant que module . Comment aborderiez-vous ce cas? Nous piratons actuellement la configuration du webpack et corrigeons le regex de test des chargeurs, mais cela semble sale comme vous pouvez l'imaginer.

J'imagine que .module.css supporte le postCSS tout comme le font actuellement le .css global.

Je sais ce qui se passe, je pense que j'ai besoin de vacances.

Lors de l'examen du PR: https://github.com/zeit/next.js/pull/9686, j'ai pensé que j'avais "vu" que les modules CSS étaient importés avec une portée tout comme les modules globaux sont importés.

J'ai sincèrement cru lire ce code:

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>
  )
}

Evidemment rien à voir avec la réalité. En réalité, le vrai code est celui-ci.

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

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

Juste des modules CSS comme dans CRA ou Gatsby. D'où la confusion, ma confusion.

Je m'excuse auprès de tout le monde pour l'erreur.

:-(

Lorsque vous utilisez des modules CSS, le principal problème est que:

Utilisez des modules CSS dans mon projet, et certains composants tiers utilisent également des modules CSS.
Mais ... certains composants tiers utilisent le CSS global.

Je pense que la solution de l'extension .module.css est facile à comprendre et à implémenter.
Et les autres cadres (CRA 、 Gatsby) sont parvenus à un consensus.

Jusqu'à présent, je n'ai rencontré aucun problème concernant la solution d'extension.
J'espère donc promouvoir le développement de l'extension .module.css .

S'il existe une autre solution au problème des modules CSS, c'est mieux.

@bySabi
Bien que .m.css soit plus court, je ne pense pas que ce soit mieux.
Est-ce min.css ou module.css ?

@ xyy94813 ou exactement le contraire, toutes les importations css sont des modules, les fichiers avec .global.scss seront globaux

@felixmosh
Mais, ce n'est pas convivial pour les composants publiés.

Je pense que la convention est une bonne valeur par défaut, mais que certaines options de configuration spécifiques aux modules CSS devraient éventuellement être rendues disponibles, par exemple celles qui sont passées à css-loader , car certains utilisateurs voudront contrôler la façon dont le "scoped" les noms de classe sont affichés. Une option pourrait être ajoutée pour fournir un regex qui détermine quels fichiers CSS sont chargés en tant que "modules"

car certains utilisateurs voudront contrôler la manière dont les noms de classe "étendus" sont générés

Des exemples de pourquoi vous voudriez cela? Je ne peux penser à aucun.

Des exemples si pourquoi vous voulez cela? Je ne peux penser à aucun.

@timneutkens Eh bien, je préférerais peut-être afficher un modèle de nommage qui se conforme fondamentalement au modèle de nommage de mes classes globales avec seulement la chaîne de portée à la fin.
Au-delà de cela, je pensais à des scénarios de purge ou de fractionnement ou de chargement post-build dans lesquels je pourrais vouloir mettre en liste blanche un certain espace de noms, mais je n'ai pas encore résolu cela.

Je pense qu'il est important de se rappeler qu'un cadre avisé est destiné à prendre des décisions à votre place afin d'éliminer la configuration initiale et de renforcer l'uniformité.

Certaines de ces décisions doivent être accompagnées de valeurs par défaut qui peuvent être modifiées via des options de configuration ou des extensions, mais avec tout ce que vous rendez personnalisable, vous augmentez la base de code, ce qui crée plus de code à tester, à maintenir et à documenter qui à son tour doit également être maintenu.

Quelque chose comme le modèle de hachage de sortie scoped est si granulaire si vous arrivez à un point où vous _doit_ écraser la valeur par défaut, il est probable que vous soyez au point où vous devriez simplement écrire le chargeur personnalisé dont vous avez besoin vous-même.

Lorsque je travaille avec de nouveaux développeurs React, j'ai toujours trouvé beaucoup plus facile de transmettre le concept de styles de portée à un composant via className. Donnez simplement à l'élément externe de votre composant un nom de classe unique, généralement le même que le nom de votre composant, et écrivez votre style comme ceci si vous utilisez SCSS:

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

Je vois certainement les avantages de css-modules , mais je crains un peu qu'en ne supportant plus la méthode ci-dessus, Next.js finisse par devenir moins convivial pour les nouveaux développeurs. C'est peut-être un bon compromis à faire si vous voyez beaucoup de gens rencontrer des problèmes de commande css, mais je me demande si l'application de css-modules pourrait au moins être désactivée via next.config.js . Ou peut-être que nous pourrions même avoir une vérification au moment de la construction qui garantit que tous les styles sont correctement étendus avec un nom de classe unique, bien que nous ne sachions pas comment cela est techniquement faisable.

Je crains un peu qu'en ne supportant plus la méthode ci-dessus, Next.js finisse par devenir moins convivial pour les nouveaux développeurs

Sauf si j'ai mal compris quelque chose, je ne pense pas que les modules CSS soient exclusifs, mais le chargeur n'appliquerait l'analyseur des modules CSS que si le fichier que vous importez a le modèle de dénomination *.module.css , ou *.module.scss d'ailleurs

@ lunelson-bl

C'est semi-exclusif par opposition à la façon dont CRA ou Gatsby n'activent l'analyseur que lorsque vous utilisez le modèle de dénomination Next interdirait l'importation directe de non-module dans le composant JS.

De la RFC:

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

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

Pour utiliser des classes non-module, vous devez importer la feuille de style dans votre feuille de style globale qui n'est importée que dans _app.js (si vous voulez qu'elles soient divisées et colocalisées avec vos fichiers de composants). Sinon, ils devraient être placés directement dans cette feuille de style globale.

Je suis un nouvel utilisateur de next.js. Après avoir lu ce numéro, je me sens un peu confus. Je pense que le if the next.js prend en charge le support build-in-css-support , donc nous n'avons pas besoin du plugin @ next-css, mais cela ne fonctionne pas et génère une erreur sur "ModuleParseError".
Si j'ajoute le plugin @ next-css pour ajouter le support des importations CSS, cela fonctionne, alors comment build-in-css-support sans @ next-css, pouvez-vous fournir un exemple?
Merci a tous.

Je suis un nouvel utilisateur de next.js. Après avoir lu ce numéro et je suis un peu confus. Je pense que next.js prend en charge le support build-css , donc nous n'avons pas besoin du plugin @ next-css, mais il ne fonctionne pas et n'obtient pas d'erreur sur "ModuleParseError".
Si je l'ajoute au plugin @ next-css pour ajouter la prise en charge de l'importation CSS, cela fonctionne, alors comment créer css-build sans @ next-css, pouvez-vous donner un exemple?
merci @ALL .

ajoutez une configuration à votre next.config.js comme ceci:

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

@erkanunluturk merci, c'est bon, mais a un avertissement de fonctionnalité expérimentale, est-ce important?
Et comment est-il compatible avec antd? Je sais qu'avec-ant-design c'est ok.

@Timer pouvez-vous fournir un exemple d'importation ant-design use [RFC] css support? Merci.

J'ai toujours un problème avec Router.push ("/") lorsque je suis sur un autre lien. Quelqu'un a une solution pour cela? S'il vous plaît aidez-moi merci beaucoup

: avertissement: veuillez cesser d'utiliser ce fil pour souhaiter bonne chance et émettre un suivi. Ceci est une RFC et ils sont toujours en train de l'implémenter.

Le dernier commentaire significatif de l'équipe est https://github.com/zeit/next.js/issues/8626#issuecomment -531415968 Vous pouvez évaluer l'implémentation actuelle en l'activant via https://github.com/zeit/next .js / issues / 8626 # issuecomment -568736218

Je manque la possibilité de suivre le travail. Comment pouvons nous aider? @Timer est-il possible de connecter ce RFC avec des jalons, une feuille de route? Que fait-on à partir des points de la RFC?

Aucune idée, comment rester sur la bonne voie: confus:

@StarpTech cette RFC est complètement implémentée; Les modules CSS et CSS globaux fonctionnent selon la description RFC.

Vous pouvez tester les deux avec le seul drapeau expérimental!

Je vais verrouiller ce fil pour éviter toute prolifération des notifications. Si quelqu'un identifie des problèmes, veuillez ouvrir un nouveau problème et faites-le nous savoir! Nous publierons ici lorsque le support sera officiellement marqué comme stable (et activé par défaut).

Atterri en 9.2: https://nextjs.org/blog/next-9-2