Nosotros, el front-end, tenemos una categoría de herramientas que no resuelven los problemas que enfrentamos, sino que afectan el proceso de resolverlos. Cambialo. La actitud hacia tales herramientas es muy diferente: comenzando por la manía en el espíritu de "empujemos esto en todas partes, es genial" y termina con excusas como "si no resuelve el problema comercial, entonces no lo necesitamos". Pero, de todos modos, hoy hablaremos de PostCSS, una de esas herramientas.
La ola exagerada ha pasado mucho tiempo; en los últimos años, se ha dicho muy poco sobre PostCSS. Muchos principiantes ni siquiera saben lo que es. Creo que es hora de ver esta herramienta desde el punto de vista del uso práctico en los proyectos más comunes, donde las personas resuelven problemas y no juegan con tecnologías de moda.
PostCSS vs SASS
Oh ... Aparentemente algunas palabras sobre esto. Creo que ahora una fuente tipográfica rara no se reunió con los preprocesadores. SASS o mi LESS favorito, con menos frecuencia Stylus, se usan tanto en proyectos grandes como en proyectos pequeños. Alguien está tratando de exprimirlos al máximo, alguien usa un conjunto minimalista: anidamiento, variables, importaciones. Pero, de una forma u otra, estas herramientas ayudan con los problemas de sintaxis. Nos hacen más fácil escribir código.
Hace unos dos o tres años, PostCSS se comparó constantemente con los preprocesadores. Y eso es comprensible. Formalmente, al usarlo puede hacer lo mismo, crear algún tipo de sintaxis que sea más conveniente que CSS puro. Pero todo esto causó una gran masa, principalmente porque todos con la ayuda de PostCSS hicieron algo diferente. Innumerables complementos desconocidos, millones de combinaciones, y aparte del autor de esta o aquella configuración, nadie entendió cómo funciona y qué hace. Es como Vim o Emacs: puedes hacer una nave espacial con ellos, pero será muy difícil enseñarle a otro desarrollador cómo usarlo.
Pero si descartamos estas comparaciones, PostCSS es una herramienta que nos permite tomar nuestro CSS y hacer algo con él. Nadie se molesta en usar SASS por el bien de la sintaxis, y después del ensamblaje, pegue PostCSS y haga algo con el resultado. No se contradicen entre sí.
Viejo no significa inactivo
Recientemente, ha estado de moda para nosotros crear cosechadoras que puedan hacer todo lo que solo se nos ocurra, y su desarrollo nunca se detiene. Y si no hay confirmaciones nuevas en el repositorio durante un par de meses, entonces todo, podemos suponer que está desactualizado y ahora lo usamos, no se vuelve falso. Exageraré, por supuesto, pero creo que usted mismo notó lo absurdo que esto a veces viene.
En el mundo PostCSS, generalmente un complemento resuelve un problema. Puedes ver elementos de la filosofía de Unix aquí. De esto se deduce una conclusión lógica: si el complemento ya está resolviendo su tarea, entonces no se necesita hacer nada más. Puede encontrar complementos que no se han actualizado durante años, pero esto no significa que de repente hayan dejado de resolver las tareas para las que fueron creados.
Pero comencemos ... He reunido una docena de complementos, que en la práctica han demostrado su capacidad para simplificar la vida de los diseñadores de diseño y ahorrar tiempo durante el desarrollo. Pero siempre puedes agregar algo en los comentarios.
No 1. Doiuse
https://github.com/anandthakker/doiuse
Creo que todos enfrentamos este problema: escribes el código, verificas en Chrome, todo está bien. Usted verifica en FF - aprox. Y luego en Safari móvil todo se desmorona. O en el borde. Y te sientas y no entiendes lo que está mal. Luego observa el código durante mucho tiempo, bebe té y, de repente, llega una idea de que algunas propiedades no son compatibles con algún navegador. Vas a Caniuse y ves la confirmación de lo obvio.
Por supuesto, con experiencia, las propias manos recuerdan qué propiedades deben evitarse, pero sucede cualquier cosa. No puede dormir lo suficiente, puede haber plazos y nervios ajustados, la lista de navegadores que deben cambiarse puede cambiar. Y luego la experiencia comenzará a fallar. Doiuse es una herramienta que ayuda mucho en tales situaciones.
El principio de funcionamiento es simple: le proporcionamos una lista de navegadores y nuestro CSS. El complemento va a la base de datos de caniuse y en tiempo real nos da la respuesta que usamos de lo que no es compatible.
Podemos configurar la lista de navegadores directamente en package.json. Simple y conveniente PostCSS usa la lista de navegadores y, si no la ha visto antes, se ve así:
"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ]
También hay una configuración de doiuse, en la que puede forzarla a ignorar algunos grupos de propiedades si está seguro de que no afecta nada. Por ejemplo, si usa polyfiles o por la pérdida de soporte de alguna propiedad, nada cambiará:
ignore: [ 'will-change', 'object-fit' ]
El registro estándar proporcionado por el complemento no es muy legible. Contiene mucha información y no es muy conveniente percibirla. Pero esto es reparable. En la misma configuración, podemos hacer nuestra función para crear un registro.
Use console.log para descubrir cómo funciona el objeto que pasa PostCSS a esta función. Hay muchas cosas interesantes
Mi práctica ha demostrado que la opción más conveniente es mostrar selectores y propiedades específicas que no son compatibles, sin especificar navegadores y líneas de código. Si el proyecto usa BEM o algunos análogos, y el código del componente se distribuye en archivos separados, entonces este enfoque le permite encontrar rápidamente un lugar problemático sin cargar el cerebro.
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`); }
Para no escribir secuencias especiales de caracteres para colores en la consola, puede conectar el paquete de colores , será más conveniente con él.
Al construir, habrá algo como esto en la consola:
NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }
No 2. Autoprefixer
https://github.com/postcss/autoprefixer
Incluso es vergonzoso hablar de él, pero con demasiada frecuencia veo personas que en 2019 escriben prefijos con sus manos y todavía les aseguran a los demás que saben exactamente cuáles son necesarios y cuáles no. Dichas acciones conducen al hecho de que el código está cubierto de un montón de prefijos innecesarios y se vuelve completamente ilegible. Esto afecta la productividad laboral. Por otro lado, si necesitas el apoyo de los dinosaurios, siempre puedes olvidar algo. Por lo tanto, vale la pena deshacerse del trabajo manual al resolver este problema.
El autoprefixer funciona con la misma base de datos caniuse, usa la misma lista de navegadores y puede agregar al CSS los prefijos que realmente se necesitan en los navegadores que especificamos. Al mismo tiempo, el código en sí mismo se vuelve más limpio y el trabajo va más rápido.
Número 3. Pelusa
https://github.com/stylelint/stylelint
Cuando imprime mucho y rápidamente, tarde o temprano comienza a cometer muchos errores sin darse cuenta por completo de ellos. El ojo está borroso. En el caso de CSS, esto puede dar un efecto divertido (en realidad no) cuando mira en el navegador: ve un problema con el diseño. Miras el código, no está allí. Miras en el navegador, lo es. Pero en el código, no. Como resultado, puede buscar un problema difícil durante mucho tiempo, sin darse cuenta de que acaba de entender. Para evitar esto, inventó linter.
Stylelint es una opción popular. Sabe cómo trabajar con la sintaxis de los principales preprocesadores, conoce las últimas tendencias en CSS, puede personalizarlo a su gusto: las configuraciones son similares a las de eslint. Formalmente, esta herramienta se puede usar por sí sola, sin PostCSS, pero sin mencionar que aquí estaría mal.
Numero 4. Postcss-flexbugs-fixes
https://github.com/luisrudge/postcss-flexbugs-fixes
O, en un sentido más amplio, postcss-fixes , que incluye este complemento. Lenta, pero seguramente, las flexiones suplantan el antiguo enfoque de diseño en flotadores. Esto es bueno, pero todos sabemos que hay un montón de errores asociados con ellos. Se describen en el repositorio de flexbugs . Algunos de ellos requieren atención especial, pero también hay algunos que son tan simples que constantemente salen volando de tu cabeza. Por ejemplo, IE ignora la función calc en la abreviatura de la propiedad flex. Esto no es a menudo necesario, pero si es necesario, entonces sus manos pueden escribir una versión resumida y luego debe pensar durante mucho tiempo cuál es el problema. Afortunadamente, esto se puede solucionar automáticamente. El complemento postcss-flexbugs-fixes viene al rescate.
En el ejemplo de calc, encontrará fragmentos como este en el código:
.foo { flex: 1 0 calc(1vw – 1px); }
Y desplegarlos:
.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); }
Simple y conveniente
No 5. Postcss-preset-env
https://github.com/csstools/postcss-preset-env
Como estamos hablando del soporte del navegador, no estará fuera de lugar decir sobre postcss-preset-env. Anteriormente, cssnext desempeñaba el mismo papel. Este complemento será útil si está interesado en las nuevas tendencias en CSS.
Técnicamente, muchas de las innovaciones se pueden implementar utilizando los métodos antiguos, simplemente serán largas, detalladas y feas. Preset-env lo ayuda a escribir código de una manera nueva, a ahorrar tiempo en esto y luego a convertirlo a una versión antigua y confiable. Por supuesto, algunas cosas, como las propiedades personalizadas, no se implementan en absoluto en los navegadores más antiguos, por lo que se utilizarán las fallas allí.
Como puedes adivinar por el nombre del instrumento, se parece al mismo nombre preestablecido en Babel. Aquí, todo es igual: hay muchos convertidores ensamblados en un conjunto estable. Algunas transformaciones requieren la conexión posterior de scripts polifílicos en el cliente, pero la mayoría son implementadas únicamente por CSS. Por lo que yo entiendo, para Stage2 + los scripts no son necesarios. En cualquier caso, no me encontré con su necesidad. Corrígeme si me perdí algo allí.
No 6. Postcss-animation
https://github.com/zhouwenbin/postcss-animation
A menudo escucho de diferentes personas (principalmente backends que no son muy fuertes en CSS) que quieren usar animaciones separadas de animate.css , pero consideran que es una mala idea conectar toda la biblioteca. Es bastante lógico. Pero como resultado, pasan mucho tiempo tratando de repetir estas animaciones por su cuenta.
El complemento postcss-animation acelera enormemente este proceso. Solo escribimos el nombre de la animación, por ejemplo:
.foo { animation-name: bounce; }
Y saca la implementación de animate.css y la inserta en el código.
.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); } }
Número 7. Selectores de lista
https://github.com/davidtheclark/list-selectors
Cuando tiene varias máquinas de escribir y muchos estilos, surge la pregunta de la revisión de código, que sería bueno ver a veces con sus ojos el panorama general con todos los selectores que tenemos. Sepa qué ID se utilizan, si hay selectores de etiquetas o qué tan bien se está siguiendo la metodología aceptada. Esto es especialmente importante cuando verifica el código de principiante, que puede escribir cosas extrañas que funcionarán formalmente, pero que en realidad van en contra de los acuerdos aceptados (lejos de todas partes, estos acuerdos están bien arreglados y existe la oportunidad de automatizar tales cosas). Desplácese por numerosas hojas de estilo usted mismo para verificar la adecuación de los selectores durante mucho tiempo. Necesitamos una forma de aislarlos y mostrarlos por separado. Los selectores de lista simplemente resuelven este problema.
Al igual que doiuse, este complemento le permite usar su función para preparar información para mostrar. Puede mostrar solo lo que le interesa o pintar todo en diferentes colores. Como un ejemplo:
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); })
Este ejemplo produce una larga lista de selectores:
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', . . .
Numero 8. CSS inmutable
https://github.com/johno/immutable-css
Otra cosa a tener en cuenta es la interrupción de estilos de bibliotecas de terceros. Si conectamos algún tipo de biblioteca, y luego comenzamos a escribir nuestros propios estilos para los selectores de la misma, al final obtenemos un código confuso en el que no podemos distinguir de qué proviene. Esto puede conducir a errores aleatorios, que luego toman demasiado tiempo de la nada. Cuantas más veces redefinamos algo, más difícil será en última instancia comprender lo que está sucediendo, aunque el problema en sí que debe resolverse puede ser muy simple. En esta situación, una herramienta llamada immutable-css podría ser útil.
En general, el principio de su trabajo es simple: toma archivos con estilos, si encuentra coincidencias en los selectores, comienza a indignarse:
! .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]
El único problema con esta herramienta es que no admite sintaxis que no sea CSS. Entonces, si se usan preprocesadores en el proyecto, entonces los archivos ya ensamblados tienen que ser comparados. Pero, en general, si la tarea es simplemente asegurarse de que nadie reescribe accidentalmente los estilos de una biblioteca de terceros, entonces esto no es tan importante.
No 9. Bye-Bye!
https://github.com/AoDev/css-byebye
Creo que todos están familiarizados con la situación cuando agregamos gradualmente algunos componentes a un sitio de trabajo. Algunos de ellos van inmediatamente a la producción, y otros se sientan por mucho tiempo y esperan su turno (por ejemplo, inventamos, todavía no terminamos el backend). Algo puede ser un experimento o una solución temporal para las vacaciones. Puede haber muchas situaciones, pero están unidas por el hecho de que tenemos un montón de componentes, y solo una pequeña parte de ellos se usa en el sitio de combate. Sería bueno eliminar todo lo que no se usa del ensamblaje actual. Esto puede reducir significativamente su tamaño, así como reducir un dolor de cabeza en el futuro, cuando será necesario hacer un rediseño, por ejemplo, y la pregunta será, ¿qué de todo esto realmente necesita reescribirse ahora y qué no?
Existen diferentes enfoques para este problema. Uncss viene inmediatamente a la mente . Esta herramienta detecta automáticamente qué estilos se usan en las páginas y elimina los innecesarios. Pero en la práctica, esto casi siempre lleva al hecho de que nadie sabe qué se está utilizando realmente y qué no. También dudo todo el tiempo si esta herramienta ha eliminado algo superfluo. Pero esta es probablemente mi paranoia. Aunque ...
Bye-bye es una herramienta más simple que nosotros mismos alimentamos con una lista de selectores para eliminar de CSS. Y puedes usar expresiones regulares. Si usa BEM o algo así, con un simple regular puede eliminar un bloque con todo lo relacionado con él. Adios
Este enfoque resultó ser bastante conveniente. Está claro de inmediato qué estilos aún no se usan o se han eliminado como innecesarios, mientras que todas las fuentes están en su lugar, todas las configuraciones en un archivo, no se pierde nada, no causa dificultades para hacer varios ensamblajes diferentes, y lo más importante, la solución es simple y predecible.
No 10. Postcss-trolling
https://github.com/juanfran/postcss-trolling
Todas las herramientas anteriores pueden aumentar ligeramente la productividad de sus diseñadores de diseño, pero esta ofrece resultados simplemente fenomenales. Lo recomiendo mucho
Conclusión
PostCSS es una buena ayuda para un diseñador de maquetación. Si no se abusa de ellos, por supuesto. Para muchos problemas que requieren mucho tiempo, existen soluciones preparadas en forma de complementos, y aunque a menudo no se desarrollan y parecen abandonados, esto no interfiere con su uso.