Nous, le front-end, avons une catégorie d'outils qui ne résolvent pas les problèmes auxquels nous sommes confrontés, mais affectent plutôt le processus de leur résolution. Changez-le. L'attitude envers de tels outils est très différente - à partir de la manie dans l'esprit de «poussons cette chose partout, c'est tellement cool» et se terminant par des excuses comme «si cela ne résout pas le problème commercial, alors nous n'en avons pas besoin». Mais, de toute façon, nous parlerons aujourd'hui de PostCSS - l'un de ces outils.
La vague de battage médiatique est depuis longtemps passée; ces dernières années, très peu de choses ont été dites sur PostCSS. Beaucoup de débutants ne savent même pas ce que c'est. Je pense qu'il est temps de regarder cet outil du point de vue de son utilisation pratique dans les projets les plus ordinaires, où les gens résolvent des problèmes, plutôt que de jouer avec des technologies à la mode.
PostCSS vs SASS
Oh ... Apparemment, quelques mots à ce sujet. Je pense que maintenant un typographe rare n'a pas rencontré de préprocesseurs. SASS ou mon LESS préféré, moins souvent Stylus, sont utilisés à la fois sur les grands projets et sur les petits. Quelqu'un essaie d'en tirer le meilleur parti, quelqu'un utilise un ensemble minimaliste - imbrication, variables, importations. Mais, d'une manière ou d'une autre, ces outils aident à résoudre les problèmes de syntaxe. Ils nous facilitent l'écriture de code.
Il y a environ deux ou trois ans, PostCSS était constamment comparé aux préprocesseurs. Et c'est compréhensible. Formellement, en l'utilisant, vous pouvez faire la même chose, créer une sorte de syntaxe qui sera plus pratique qu'un CSS pur. Mais tout cela a provoqué une masse bouillonnante, principalement parce que tout le monde avec l'aide de PostCSS a fait quelque chose de différent. D'innombrables plugins inconnus, des millions de combinaisons, et à part l'auteur de telle ou telle configuration, personne n'a compris comment cela fonctionne et ce qu'il fait. C'est comme Vim ou Emacs - vous pouvez en faire un vaisseau spatial, mais il sera très difficile d'enseigner à un autre développeur comment l'utiliser.
Mais si nous rejetons ces comparaisons, PostCSS est un outil qui nous permet de prendre notre CSS et de faire quelque chose avec. Personne ne prend la peine d'utiliser SASS pour des raisons de syntaxe, et après l'assemblage, collez PostCSS et faites quelque chose avec le résultat. Ils ne se contredisent pas.
Vieux ne veut pas dire inactif
Récemment, il a été à la mode pour nous de créer des moissonneuses-batteuses capables de faire tout ce qui vient à l'esprit, et leur développement ne s'arrête jamais. Et s'il n'y a pas de nouveaux commits dans le référentiel pendant quelques mois, alors tout - nous pouvons supposer qu'il est obsolète et l'utiliser maintenant - pas comme il faut. Je vais exagérer, bien sûr, mais je pense que vous avez vous-même remarqué à quel point cela peut parfois arriver.
Dans le monde PostCSS, généralement un plugin résout un problème. Vous pouvez voir des éléments de la philosophie Unix ici. Une conclusion logique en découle - si le plug-in résout déjà son problème, il n'y a plus rien à faire avec. Vous pouvez trouver des plugins qui n'ont pas été mis à jour depuis des années, mais cela ne signifie pas qu'ils ont soudainement cessé de résoudre les tâches pour lesquelles ils ont été créés.
Mais commençons ... J'ai rassemblé une douzaine de plug-ins qui, dans la pratique, ont montré leur capacité à simplifier la vie des concepteurs de mise en page et à gagner du temps lors du développement. Mais vous pouvez toujours ajouter quelque chose dans les commentaires.
N ° 1. Doiuse
https://github.com/anandthakker/doiuse
Je pense que nous avons tous été confrontés à ce problème: vous écrivez le code, vérifiez dans le chrome - tout va bien. Vous vous enregistrez en FF - env. Et puis, dans Safari mobile, tout s'écroule. Ou dans Edge. Et vous vous asseyez et ne comprenez pas ce qui ne va pas. Ensuite, vous regardez le code pendant longtemps, buvez du thé, et tout à coup, il apparaît que certaines propriétés ne sont pas prises en charge dans certains navigateurs. Vous allez sur caniuse et vous voyez la confirmation de l'évidence.
Bien sûr, avec l'expérience, les mains elles-mêmes se souviennent des propriétés à éviter, mais tout se passe. Vous ne pouvez pas dormir suffisamment, les délais et les nerfs peuvent être serrés, la liste des navigateurs à changer peut changer. Et puis l'expérience commencera à échouer. Doiuse est un outil qui aide beaucoup dans de telles situations.
Le principe de fonctionnement est simple - nous lui fournissons une liste de navigateurs et notre CSS. Le plugin va à la base de données caniuse et nous donne en temps réel la réponse que nous avons utilisée à partir de ce qui n'est pas supporté.
Nous pouvons définir la liste des navigateurs directement dans package.json. Simple et pratique. PostCSS utilise une liste de navigateurs et, si vous ne l'avez pas encore vue, elle ressemble à ceci:
"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ]
Il existe également une configuration de doiuse elle-même, dans laquelle vous pouvez l'obliger à ignorer certains groupes de propriétés si vous êtes sûr qu'elle n'affecte rien. Par exemple, si vous utilisez des polyfichiers ou suite à la perte de prise en charge d'une propriété, rien ne changera:
ignore: [ 'will-change', 'object-fit' ]
Le journal standard fourni par le plugin n'est pas très lisible. Il contient beaucoup d'informations et il n'est pas très pratique de le percevoir. Mais c'est réparable. Dans la même configuration, nous pouvons faire notre fonction pour créer un journal.
Utilisez console.log pour comprendre comment fonctionne l'objet qui transmet PostCSS à cette fonction. Il y a beaucoup de choses intéressantes.
Ma pratique a montré que l'option la plus pratique consiste à afficher les sélecteurs et les propriétés spécifiques qui ne sont pas pris en charge, sans spécifier de navigateurs et de lignes de code. Si le projet utilise BEM ou certains analogues et que le code du composant est distribué dans des fichiers séparés, cette approche vous permet de trouver rapidement un endroit problématique sans charger le cerveau.
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`); }
Afin de ne pas écrire de séquences spéciales de caractères pour les couleurs dans la console, vous pouvez connecter le package de couleurs , il sera plus pratique avec lui.
Lors de la construction, il y aura quelque chose comme ça dans la console:
NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }
N ° 2. Autoprefixer
https://github.com/postcss/autoprefixer
C'est même embarrassant de parler de lui, mais trop souvent je vois des gens qui en 2019 écrivent des préfixes avec leurs mains et assurent toujours aux autres qu'ils savent exactement lesquels sont nécessaires et lesquels ne le sont pas. De telles actions conduisent au fait que le code est envahi par un tas de préfixes inutiles et devient complètement illisible. Cela affecte la productivité du travail. D'un autre côté, si vous avez besoin du soutien de dinosaures, vous pouvez toujours oublier quelque chose. Il vaut donc mieux se débarrasser du travail manuel pour résoudre ce problème.
L'autopréfixeur fonctionne avec la même base de données caniuse, utilise la même liste de navigateurs et peut ajouter au CSS les préfixes qui sont vraiment nécessaires dans les navigateurs que nous avons spécifiés. En même temps, le code lui-même devient plus propre et le travail va plus vite.
Numéro 3. Stylelint
https://github.com/stylelint/stylelint
Lorsque vous imprimez beaucoup et rapidement, tôt ou tard, vous commencez à faire de nombreuses erreurs sans les remarquer complètement. L'œil est flou. Dans le cas de CSS, cela peut donner un effet amusant (en fait pas) lorsque vous regardez dans le navigateur - vous voyez un problème de mise en page. Vous regardez le code - il n'est pas là. Vous regardez dans le navigateur - ça l'est. Mais dans le code - non. En conséquence, vous pouvez rechercher un problème difficile pendant une longue période, sans vous rendre compte que vous venez juste de faire le tour. Pour éviter cela, inventé linter.
Stylelint est une option populaire. Il sait travailler avec la syntaxe des principaux préprocesseurs, il connaît les dernières tendances en CSS, il peut le personnaliser à son goût - les configs sont similaires à celles d'eslint. Formellement, cet outil peut être utilisé seul, sans PostCSS, mais ne pas le mentionner ici serait faux.
Numéro 4. Postcss-flexbugs-fixes
https://github.com/luisrudge/postcss-flexbugs-fixes
Ou dans un sens plus large, postcss-fixes , qui inclut ce plugin. Lentement, mais sûrement, les flexions supplantent l'ancienne approche de la disposition sur les flotteurs. C'est bien, mais nous savons tous qu'un tas de bugs leur sont associés. Ils sont décrits dans le référentiel flexbugs . Certains d'entre eux nécessitent une attention particulière, mais il y en a aussi quelques-uns qui sont si simples qu'ils sortent constamment de votre tête. Par exemple, IE ignore la fonction calc dans la sténographie de la propriété flex. Ce n'est pas si souvent nécessaire, mais si nécessaire, alors vos mains peuvent écrire une version abrégée et ensuite vous devez réfléchir longtemps au problème. Heureusement, cela peut être corrigé automatiquement. Le plugin postcss-flexbugs-fixes vient à la rescousse.
Dans l'exemple de calc, il trouvera des fragments comme celui-ci dans le code:
.foo { flex: 1 0 calc(1vw – 1px); }
Et déployez-les:
.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); }
Simple et pratique.
N ° 5. Postcss-preset-env
https://github.com/csstools/postcss-preset-env
Puisque nous parlons de la prise en charge du navigateur, il ne sera pas hors de propos de parler de postcss-preset-env. Auparavant, cssnext jouait le même rôle. Ce plugin sera utile si vous êtes intéressé par les nouvelles tendances CSS.
De nombreuses innovations peuvent être mises en œuvre techniquement en utilisant les anciennes méthodes, elles seront simplement longues, prolixes et laides. Preset-env vous aide à écrire du code d'une nouvelle manière, à gagner du temps à ce sujet, puis à le convertir en une ancienne version fiable. Bien sûr, certaines choses comme les propriétés personnalisées ne sont pas du tout implémentées dans les navigateurs plus anciens, donc les solutions de secours y seront utilisées.
Comme vous pouvez le deviner d'après le nom de l'instrument, il ressemble au même nom prédéfini chez Babel. Ici, tout est pareil - il existe de nombreux convertisseurs assemblés en un seul ensemble stable. Certaines transformations nécessitent une connexion ultérieure de scripts polyphiles sur le client, mais la plupart sont implémentées uniquement par CSS. Pour autant que je comprends, pour les scripts Stage2 + ne sont pas nécessaires. En tout cas, je n'ai pas rencontré leur besoin. Corrigez-moi si j'ai raté quelque chose là-bas.
N ° 6. Postcss-animation
https://github.com/zhouwenbin/postcss-animation
Souvent, j'entends de différentes personnes (principalement des backends qui ne sont pas très forts en CSS) qu'ils veulent utiliser des animations distinctes d' animate.css , mais considèrent que c'est une mauvaise idée de connecter toute la bibliothèque. C'est tout à fait logique. Mais en conséquence, ils passent beaucoup de temps à essayer de répéter ces animations par eux-mêmes.
Le plugin postcss-animation accélère considérablement ce processus. Nous écrivons uniquement le nom de l'animation, par exemple:
.foo { animation-name: bounce; }
Et il récupère l'implémentation depuis animate.css et l'insère dans le code.
.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); } }
Numéro 7. Sélecteurs de liste
https://github.com/davidtheclark/list-selectors
Lorsque vous avez plusieurs typographes et de nombreux styles, la question se pose de la révision du code, qu'il serait bien de voir parfois avec vos yeux la vue d'ensemble avec tous les sélecteurs que nous avons. Sachez quels ID sont utilisés, s'il existe des sélecteurs de balises ou si la méthodologie acceptée est bien suivie. Cela est particulièrement important lorsque vous vérifiez le code du débutant, qui peut écrire des choses étranges qui fonctionneront officiellement, mais qui vont en fait à l'encontre des accords acceptés (loin de partout, ces accords sont bien fixés et il est possible d'automatiser de telles choses). Faites défiler vous-même de nombreuses feuilles de style pour vérifier l'adéquation des sélecteurs pendant longtemps. Nous avons besoin d'un moyen de les isoler et de les montrer séparément. Les sélecteurs de liste ne font que résoudre ce problème.
Tout comme doiuse, ce plugin vous permet d'utiliser sa fonction pour préparer les informations à afficher. Vous pouvez afficher uniquement ce qui vous intéresse ou tout peindre de différentes couleurs. A titre d'exemple:
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); })
Cet exemple produit une longue, longue liste de sélecteurs:
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', . . .
Numéro 8. Immutable-CSS
https://github.com/johno/immutable-css
Une autre chose à surveiller est l'interruption des styles des bibliothèques tierces. Si nous avons connecté une sorte de bibliothèque, puis que nous commençons à en écrire nos propres styles pour les sélecteurs, nous obtenons finalement un code déroutant dans lequel nous ne pouvons pas déterminer ce qui est venu. Cela peut conduire à des bugs aléatoires, qui prennent alors trop de temps à l'improviste. Plus nous redéfinissons quelque chose, plus il est difficile de comprendre ce qui se passe, même si le problème lui-même qui doit être résolu peut être très simple. Dans cette situation, un outil appelé immutable-css peut être utile.
En général, le principe de son travail est simple: il prend des fichiers avec des styles, s'il trouve des correspondances sur des sélecteurs, il commence à s'indigner:
! .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]
Le seul problème avec cet outil est qu'il ne prend pas en charge la syntaxe non CSS. Donc, si des préprocesseurs sont utilisés dans le projet, les fichiers déjà assemblés doivent être comparés. Mais en général, si la tâche consiste simplement à s'assurer que personne ne réécrit accidentellement les styles d'une bibliothèque tierce, ce n'est pas si important.
N ° 9. Au revoir!
https://github.com/AoDev/css-byebye
Je pense que tout le monde connaît la situation lorsque nous ajoutons progressivement des composants à un site de travail. Certains d'entre eux vont immédiatement à la production, et certains restent longtemps assis et attendent leur tour (par exemple, nous nous sommes réconciliés, nous n'avons pas encore fini le backend). Quelque chose peut être une expérience ou une solution temporaire pour les vacances. Il peut y avoir de nombreuses situations, mais elles sont unies par le fait que nous avons un tas de composants, et seule une petite partie d'entre eux sont utilisés sur le site de combat. Ce serait bien de supprimer tout ce qui n'est pas utilisé de l'assemblage actuel. Cela peut réduire considérablement sa taille, ainsi que réduire les maux de tête à l'avenir, quand il sera nécessaire de faire une refonte par exemple, et la question sera de savoir ce qui doit vraiment être réécrit maintenant et ce qui ne l'est pas.
Il existe différentes approches à ce problème. Uncss vient immédiatement à l' esprit . Cet outil détecte automatiquement les styles utilisés sur les pages et supprime les styles inutiles. Mais dans la pratique, cela conduit presque toujours au fait que personne ne sait ce qui est réellement utilisé et ce qui ne l'est pas. Je doute aussi tout le temps que cet outil ait supprimé quelque chose de superflu. Mais c'est probablement ma paranoïa. Bien que ...
Bye-bye est un outil plus simple que nous alimentons nous-mêmes une liste de sélecteurs à supprimer de CSS. Et vous pouvez utiliser des expressions régulières. Si vous utilisez BEM ou quelque chose d'autre comme ça, alors avec un simple régulier, vous pouvez supprimer un bloc avec tout ce qui s'y rapporte. Au revoir!
Cette approche s'est avérée assez pratique. Il est immédiatement clair quels styles ne sont pas encore utilisés ou ont été supprimés car inutiles, alors que toutes les sources sont en place, tous les paramètres dans un fichier, rien n'est perdu, cela ne cause pas de difficultés pour faire plusieurs assemblages différents, et surtout, la solution est simple et prévisible.
N ° 10. Postcss-trolling
https://github.com/juanfran/postcss-trolling
Tous les outils précédents peuvent augmenter légèrement la productivité de vos concepteurs de mise en page, mais celui-ci donne des résultats tout simplement phénoménaux. Je le recommande vivement.
Conclusion
PostCSS est une bonne aide pour un concepteur de mise en page. S'ils ne sont pas maltraités, bien sûr. Pour de nombreux problèmes chronophages, il existe des solutions toutes faites sous la forme de plug-ins, et bien qu'ils ne se développent souvent pas et semblent abandonnés, cela n'interfère pas avec leur utilisation.