CSS-in-JS , al no ser una tecnología completamente nueva e implementada en muchas bibliotecas , aún plantea dudas y debates sobre la idoneidad de su uso. Gajus Kuizinas , autor de react-css-modules y babel-plugin , estableció sus puntos sobre la "i" en disputas sobre CSS-in-JS en general, y sobre componentes con estilo en particular, hace un año (27 de abril de 2017) -react-css-modules , en la publicación actual en mi opinión "Deje de usar CSS-in-JavaScript en el desarrollo web" .
La siguiente es una traducción ligeramente resumida con algunas adiciones y conclusiones:
CSS no va a ninguna parte . En muchos proyectos, la elección del estilo en JavaScript es errónea. Enumeraremos conceptos erróneos comunes (mitos) y sus decisiones correspondientes a través de CSS.
Historia de CSS y JavaScript
CSS fue creado para describir la presentación de un documento escrito en un lenguaje de marcado. JavaScript se creó como un "pegamento de idioma" para ensamblar componentes como imágenes y complementos. Con los años, JS ha crecido y cambiado, adaptándose a nuevas áreas de aplicación. Y, como resultado, hoy vivimos en la era de las aplicaciones de una sola página (SPA), aplicaciones ensambladas a partir de componentes.
¿Qué hay de CSS?
Aquí hay una cita de la documentación de componentes con estilo :
El problema con el CSS normal es que se creó en una época en que la web estaba compuesta de documentos. La Web se creó para intercambiar documentos predominantemente científicos en 1993 y CSS se introdujo como una solución para diseñar estos documentos. Sin embargo, hoy estamos desarrollando aplicaciones desarrolladas, interactivas y orientadas al usuario, y CSS simplemente no está diseñado para esto.
Esto no es asi.
CSS ya tiene en cuenta todos los requisitos de las interfaces de usuario modernas. La cantidad de nuevas funciones implementadas en la última década es tal que es imposible incluso enumerarlas todas (pseudo-clases, pseudo-elementos, variables CSS, consultas de medios, fotogramas clave, combinadores, columnas, flex, grid, valores calculados, ...).
Desde el punto de vista de la interfaz de usuario, "componente" es un fragmento aislado del documento (<botón /> es "componente"). CSS está diseñado para dar estilo a los documentos, y el documento cubre todos los componentes. Cual es el problema
Como dice el dicho: "Use la herramienta adecuada para el trabajo".
Componentes estilizados
styled-components hace posible escribir CSS en JavaScript usando el llamado etiquetado cadenas de plantillas . La biblioteca elimina la asignación entre componentes y estilos; el componente se convierte en una construcción de estilo de bajo nivel, por ejemplo:
// Create a <Title> react component that renders an <h1> which is // centered, palevioletred and sized at 1.5em const Title = styled.h1` font-size: 1.5em; text-align: center; color: palevioletred; `;
styled-components es popular hoy y se conoce como una nueva forma de diseñar componentes en React, aunque a veces incluso se presenta como el "pináculo del desarrollo de CSS":
Evolución CSS: desde CSS, SASS, BEM, módulos CSS hasta componentes con estilo .
Pero aclaremos lo siguiente: los componentes con estilo son solo un complemento de CSS. Esta biblioteca analiza los estilos CSS que define en JavaScript y crea los elementos JSX apropiados.
La popularidad de los componentes con estilo está cargada de muchos conceptos erróneos. Una revisión de las respuestas de los programadores (que se encuentran en IRC, Reddit y Discord) a una pregunta sobre las razones que los impulsaron a usar esta biblioteca permitió hacer una lista de las más mencionadas. Llamémoslos mitos.
Mito n. ° 1: los componentes con estilo resuelven problemas globales de espacio de nombres y conflictos de estilo
Esto es un mito, porque parece que el problema supuestamente mencionado aún no se ha resuelto. Sin embargo, los módulos CSS , Shadow DOM e innumerables convenciones de nomenclatura (como BEM ) ofrecieron soluciones al problema hace mucho tiempo.
los componentes con estilo (al igual que los módulos CSS) eliminan el problema de nombrar la responsabilidad de una persona. La naturaleza humana es cometer errores; las computadoras cometen errores con poca frecuencia.
Por sí mismo, esta no es una razón suficiente para usar componentes con estilo.
Mito 2: el uso de componentes con estilo permite obtener un código más compacto.
En apoyo de esto, a menudo damos un ejemplo:
<TicketName></TicketName> <div className={styles.ticketName}></div>
En primer lugar, no importa. La diferencia es insignificante.
En segundo lugar, esto no es cierto. El número total de caracteres depende del nombre del estilo.
<TinyBitLongerStyleName></TinyBitLongerStyleName> <div className={styles.longerStyleName}></div>
Lo mismo se aplica a la creación de estilos, que veremos más adelante en este artículo.
(Mito 5: componentes con estilo facilita el estilo condicional de los componentes). los componentes con estilo ganan en brevedad solo en los casos de los componentes más básicos.
Mito 3. El uso de componentes con estilo te hace pensar más en semántica.
El mensaje original en sí mismo es erróneo. La estilización y la semántica son problemas diferentes y requieren soluciones diferentes. Lea, por ejemplo, este es Adam Morse (mrmrs) .
Sin embargo, considere:
<PersonList> <PersonListItem> <PersonFirstName>Foo</PersonFirstName> <PersonLastName>Bar</PersonLastName> </PersonListItem> </PersonList>
La semántica se ocupa del uso de las etiquetas correctas para el marcado. ¿Sabes qué etiquetas HTML se usarán para representar dicho componente? No, no lo sabes.
Compara:
<ol> <li> <span className={styles.firstName}>Foo</span> <span className={styles.lastName}>Bar</span> </li> </ol>
Mito 4: es más fácil expandir estilos.
Compara:
const Button = styled.button` padding: 10px; `; const TomatoButton = Button.extend` color: #f00; `;
Genial Pero puede hacer lo mismo en CSS (o usar la composición del módulo CSS, así como la herencia SASS mixin @extend).
button { padding: 10px; } button.tomato-button { color: #f00; }
¿Y la más simple la primera opción?
Mito 5: estilo condicional facilitado de componentes
La idea es que puede diseñar elementos usando accesorios, por ejemplo:
<Button primary /> <Button secondary /> <Button primary active={true} />
Eso tiene sentido en React. Al final, el comportamiento de los componentes se controla a través de accesorios. ¿Tiene sentido vincular directamente los valores de apoyo a los estilos? Tal vez Pero echemos un vistazo a la implementación de dicho componente:
styled.Button` background: ${props => props.primary ? '#f00' : props.secondary ? '#0f0' : '#00f'}; color: ${props => props.primary ? '#fff' : props.secondary ? '#fff' : '#000'}; opacity: ${props => props.active ? 1 : 0}; `;
Crear estilos condicionales usando JavaScript ofrece muchas posibilidades. Sin embargo, esto también significa que los estilos serán mucho más difíciles de interpretar. Comparar con CSS:
button { background: #00f; opacity: 0; color: #000; } button.primary, button.seconary { color: #fff; } button.primary { background: #f00; } button.secondary { background: #0f0; } button.active { opacity: 1; }
En este caso, CSS es más corto (229 caracteres frente a 222) y más fácil de entender (subjetivamente). Además, en CSS podría usar un preprocesador para obtener un resultado aún más corto y agrupado:
button { background: #00f; opacity: 0; color: #000; &.primary, &.seconary { color: #fff; } &.primary { background: #f00; } &.secondary { background: #0f0; } &.active { opacity: 1; } }
Mito 6: mejora la organización del código
Algunos dicen que les gustan los componentes con estilo, porque es posible colocar estilos y scripts en un archivo. Puede comprender que tener varios archivos para un componente puede parecer tedioso, pero insertar estilos y diseños en un solo archivo es terrible. Este sistema de control de versiones no solo complicará los cambios de seguimiento, sino que también conducirá a un "desplazamiento" sin fin en cualquier elemento más complicado que un simple botón.
Si realmente necesita poner CSS y JavaScript en el mismo archivo, pruebe css-literal-loader . Este último le permite crear estilos durante la compilación usando extract-text-webpack-plugin y usar la configuración de cargador estándar para manejar CSS.
Mito 7: "La experiencia del desarrollador (DX)" se está volviendo genial. ¡La herramienta es asombrosa!
Obviamente no usaste componentes con estilo.
- Si algo salió mal con los estilos, toda la aplicación se bloquea con un largo seguimiento del error. Lo opuesto a esto es CSS, donde un error en los estilos simplemente conducirá a una visualización incorrecta del elemento.
- Los elementos no tienen className distinguible, por lo que durante la depuración tendrá que cambiar sin cesar entre el árbol de elementos React y el árbol DOM de DevTools.
- Aunque ya existen complementos para linting, resaltado de código, finalización de código y otros "encantos" similares para componentes con estilo, es posible que aún no estén disponibles para su IDE. Si trabaja con finanzas en una agencia gubernamental, existe la posibilidad de que Atom IDE no esté disponible.
Mito 8: Todo se vuelve "más rápido", todo se vuelve "más fácil"
- Al final resultó que, los estilos de componentes con estilo no se pueden extraer en estática
archivo CSS (por ejemplo, el uso de extracto de texto webpack-plugin ). Esto significa que el navegador no podrá comenzar a interpretar estilos hasta que los componentes con estilo los analicen y los agreguen al DOM. - La combinación de estilos y scripts en un archivo significa que no es posible el almacenamiento en caché por separado.
- La naturaleza de los componentes con estilo es tal que todos están envueltos en HOC adicional. Y esta es una disminución innecesaria en el rendimiento. La misma falla condujo a la interrupción de react-css-modules y a la aparición de babel-plugin-react-css-modules .
- Debido al mismo HOC , la representación del lado del servidor da como resultado tamaños de marcado de documentos significativamente mayores.
- Ni siquiera intente animar componentes utilizando estilos dinámicos en lugar de fotogramas clave.
Mito 9: Existe la posibilidad de desarrollar componentes "sensibles"
Estamos hablando de la capacidad de diseñar un componente en función del entorno, por ejemplo, el tamaño del contenedor principal, el número de herederos, etc.
En primer lugar, los componentes con estilo no tienen nada que ver con esto.
Esto está más allá del alcance del proyecto. En este caso, es mejor establecer directamente los valores de estilo del componente para evitar cargas de procesador adicionales.
¡Espera un minuto, sin embargo!
La mayoría, si no todos estos problemas pueden resolverse a largo plazo, ya sea por la comunidad, por cambios en React o en los componentes con estilo. Pero por que? CSS ya es ampliamente compatible, hay una comunidad sólida y ... simplemente funciona.
Pero no siempre debe evitar el uso de CSS-in-JavaScript o componentes con estilo.
Hay algo que hace que los componentes con estilo sean una buena biblioteca: este es el mejor soporte multiplataforma.
Simplemente no use componentes con estilo basados en representaciones erróneas.
Un par de opiniones de las partes interesadas.
Usando componentes con estilo en nuestro proyecto, encontramos que hay algunas reglas de estilo que son difíciles de implementar en los componentes con estilo; por ejemplo, reglas que controlan la colocación de elementos en una página (márgenes o propiedades de visualización). Era difícil de estandarizar, por lo que aún teníamos que depender en gran medida de CSS simple para colocar componentes en la secuencia de elementos.
... aunque hubo dificultades en el uso de componentes con estilo, la biblioteca nos ayudó a reducir la base del código.
(comentario sobre "Evolución CSS: de CSS, SASS, BEM y CSS - módulos a componentes con estilo" )
... Ninguna evolución de CSS aquí significa que las herramientas evolucionan.
En mi opinión, no hay ningún problema cuando la composición tipográfica se dedica al diseño y el programador se dedica a la programación.
Pero cuando los programadores se dedican a la composición tipográfica, comienza todo este zoológico, que en lugar de SIMPLICIDAD con más apoyo, da un dolor de cabeza adicional.
...
Escriba en CSS puro y asigne a las herramientas el rol de un espacio de nombres y un recopilador; entonces todo será feliz ...
Y finalmente, una palabra para el autor:
Gajus Kuizinas: - Entonces, ¿qué, después de todo, usar?