Un lenguaje de estilo unificado

En los últimos años, hemos visto el surgimiento de CSS-in-JS, surgiendo principalmente de la comunidad React. Esto, por supuesto, no ha estado exento de controversias. Muchas personas, particularmente aquellas que ya están íntimamente familiarizadas con CSS, han mirado con incredulidad.

“¿Por qué alguien querría escribir CSS en JS?
¡Seguramente esta es una idea terrible!
¡Si tan solo aprendieran CSS! "

Si esta fue tu reacción, sigue leyendo. Vamos a ver por qué escribir sus estilos en JavaScript no es una idea tan terrible después de todo, y por qué creo que debería estar atento a este espacio en rápida evolución.

(Fuente)

Comunidades incomprendidas

La comunidad React a menudo es malentendida por la comunidad CSS, y viceversa. Esto es particularmente interesante para mí, ya que estoy atrapado en algún lugar entre estos dos mundos.

Comencé a aprender HTML a finales de los noventa, y he estado trabajando con CSS profesionalmente desde la edad oscura de los diseños basados ​​en tablas. Inspirado por CSS Zen Garden, estaba en la primera línea de la migración de bases de código existentes hacia marcado semántico y hojas de estilo en cascada. No pasó mucho tiempo después de esto que me obsesioné con separar nuestras preocupaciones, usando JavaScript discreto para decorar nuestro marcado procesado por el servidor con interacciones del lado del cliente. Había una comunidad pequeña pero vibrante en torno a estas prácticas, y nos convertimos en la primera generación de desarrolladores front-end, tratando de darle a la plataforma del navegador el respeto que merecía.

Con un fondo centrado en la web como este, puede imaginarse que me opondría con vehemencia al modelo HTML-in-JS de React, que aparentemente va en contra de los principios que tanto apreciamos, pero de hecho, es todo lo contrario. En mi experiencia, el modelo de componentes de React, junto con su capacidad de renderizar en el lado del servidor, finalmente nos brinda una forma de crear aplicaciones complejas de una sola página a escala, de una manera que aún nos permite enviar productos rápidos, accesibles y progresivamente mejorados a nuestros usuarios Incluso hemos aprovechado esta capacidad aquí en SEEK, nuestro producto estrella es una aplicación React de una sola página donde el flujo de búsqueda central todavía funciona cuando JavaScript está deshabilitado, degradando con gracia a un sitio web tradicional ejecutando el mismo código JavaScript en el servidor.

Entonces, considere esto una rama de olivo de una comunidad a otra. Juntos, intentemos comprender de qué se trata este movimiento. Puede que no sea perfecto, puede que no sea algo que planeas usar en tus productos, puede que ni siquiera sea terriblemente convincente para ti, pero al menos vale la pena intentar entenderlo.

¿Por qué CSS-in-JS?

Si está familiarizado con mi trabajo reciente con los módulos React y CSS, es posible que se sorprenda al verme defender CSS-in-JS.

Módulos CSS (Fuente)

Después de todo, los Módulos CSS generalmente son elegidos por desarrolladores que desean estilos con alcance local sin comprar CSS-in-JS. De hecho, ni siquiera uso CSS-in-JS en mi propio trabajo.

A pesar de esto, sigo manteniendo un gran interés en la comunidad CSS-in-JS, vigilando de cerca las innovaciones que continuamente presentan. No solo eso, creo que la comunidad CSS más amplia también debería estar interesada.

¿Pero por qué?

Para comprender mejor por qué las personas eligen escribir sus estilos en JavaScript, nos centraremos en los beneficios prácticos que surgen al adoptar este enfoque.

He dividido esto en cinco áreas principales:

  1. Estilos de alcance
  2. CSS crítico
  3. Optimizaciones más inteligentes
  4. Gestión de paquetes
  5. Estilo sin navegador

Analicemos esto más a fondo y echemos un vistazo más de cerca a lo que CSS-in-JS aporta a la tabla para cada uno de estos puntos.

1)

Estilos de alcance

No es ningún secreto que diseñar CSS de manera efectiva a escala es increíblemente difícil. Al unirse a un proyecto existente de larga duración, no era raro encontrar que el CSS era la parte más difícil del sistema.

Para contrarrestar esto, la comunidad CSS ha invertido mucho en tratar de abordar estos problemas, haciendo que nuestros estilos sean más sostenibles con metodologías como OOCSS de Nicole Sullivan y SMACSS de Jonathan Snook, pero el claro ganador en este momento en términos de popularidad parece ser BEM, o Modificador de elemento de bloque, de Yandex.

En última instancia, BEM (cuando se aplica únicamente a CSS) es solo una convención de nomenclatura, optando por limitar los estilos a las clases siguiendo un patrón modificador .Block__element. En cualquier base de código de estilo BEM, los desarrolladores deben recordar seguir las reglas de BEM en todo momento. Cuando se sigue estrictamente, BEM funciona realmente bien, pero ¿por qué algo tan fundamental como el alcance se deja a la convención pura?

Ya sea que lo digan explícitamente o no, la mayoría de las bibliotecas CSS-in-JS siguen la mentalidad BEM de tratar de orientar estilos a elementos individuales de la interfaz de usuario, pero implementarlo de una manera radicalmente diferente.

¿Cómo se ve esto en la práctica? Cuando se usa el glamour de Sunil Pai, se parece a esto:

importar {css} desde 'glamour'
const title = css ({
  fontSize: '1.8em',
  fontFamily: 'Comic Sans MS',
  color azul'
})
console.log (título)
// → 'css-1pyvz'

Lo que notará aquí es que la clase CSS no se encuentra en ningún lugar de nuestro código. Ya no es una referencia codificada a una clase definida en otra parte del sistema. En cambio, es generado automáticamente por la biblioteca. No tenemos que preocuparnos de que nuestros selectores choquen en el ámbito global, lo que significa que ya no tenemos que prefijarlos manualmente.

El alcance de este selector coincide con las reglas de alcance del código circundante. Si desea que esta regla esté disponible para el resto de su aplicación, deberá convertirla en un módulo de JavaScript e importarla donde sea que se use. En términos de mantener nuestras bases de código mantenibles a lo largo del tiempo, esto es increíblemente poderoso, asegurando que la fuente de cualquier estilo determinado pueda rastrearse fácilmente como cualquier otro código.

Al pasar de la mera convención a aplicar estilos con ámbito local de forma predeterminada, ahora hemos mejorado la calidad de referencia de nuestros estilos. BEM está horneado, no habilitado.

-

Antes de continuar, hay un punto críticamente importante que aclarar.

Esto está generando CSS real, no estilos en línea.

La mayoría de las primeras bibliotecas CSS-in-JS adjuntaron estilos directamente a cada elemento, pero la falla crítica en este modelo es que los atributos de "estilo" no pueden hacer todo lo que CSS puede hacer. La mayoría de las bibliotecas nuevas se centran en hojas de estilo dinámicas, insertando y eliminando reglas en tiempo de ejecución de un conjunto global de estilos.

Como ejemplo, echemos un vistazo a JSS por Oleg Slobodskoi, una de las primeras bibliotecas CSS-in-JS para generar CSS real.

JSS (fuente)

Cuando use JSS, puede usar características CSS estándar como estilos de desplazamiento y consultas de medios, que se asignan directamente a las reglas CSS equivalentes.

const styles = {
  botón: {
    relleno: '10px',
    '&: hover': {
      fondo: 'azul'
    }
  },
  '@media (ancho mínimo: 1024px)': {
    botón: {
      relleno: '20px'
    }
  }
}

Una vez que inserte estos estilos en el documento, se le proporcionarán las clases generadas automáticamente.

const {classes} = jss.createStyleSheet (estilos) .attach ()

Estas clases generadas se pueden usar en lugar de cadenas de clase codificadas al generar marcado en JavaScript. Este patrón funciona independientemente de si está utilizando un marco completo o algo tan simple como innerHTML.

document.body.innerHTML = `
  

¡Hola mundo!

``

Administrar los estilos de esta manera es poco beneficioso en sí mismo: generalmente se combina con algún tipo de biblioteca de componentes. Como resultado, es típico encontrar enlaces disponibles para las bibliotecas más populares. Por ejemplo, JSS puede unirse fácilmente a los componentes React con la ayuda de react-jss, inyectando un pequeño conjunto de estilos en cada componente mientras administra el ciclo de vida global por usted.

importar injectSheet desde 'react-jss'
const Button = ({classes, children}) => (
  
)
exportar hoja de inyección predeterminada (estilos) (Botón)

Al centrar nuestros estilos en los componentes, integrándolos más estrechamente a nivel de código, estamos llevando a BEM a su conclusión lógica. Tanto es así que muchos en la comunidad CSS-in-JS sintieron que la importancia de extraer, nombrar y reutilizar componentes se estaba perdiendo en toda la plantilla de enlace de estilo.

Una forma completamente nueva de pensar sobre este problema surgió con la introducción de componentes diseñados por Glen Maddern y Max Stoiber.

Componentes con estilo (fuente)

En lugar de crear estilos, que luego debemos vincular manualmente a los componentes, nos vemos obligados a crear componentes directamente.

importar estilo desde 'componentes con estilo'

const Title = styled.h1`
  Familia tipográfica: Comic Sans MS;
  color azul;
``

Al aplicar estos estilos, no adjuntamos una clase a un elemento existente. Simplemente representamos el componente generado.

 ¡Hola, mundo! 

Mientras que los componentes con estilo utilizan la sintaxis CSS tradicional a través de los literales de plantilla etiquetados, otros prefieren trabajar con estructuras de datos. Una alternativa notable es Glamorous de Kent C. Dodds de PayPal.

Glamoroso (Fuente)

Glamorous ofrece la misma API de primer componente que los componentes con estilo, pero opta por objetos en lugar de cadenas, eliminando la necesidad de incluir un analizador CSS en la biblioteca, lo que reduce el tamaño de la biblioteca y la huella de rendimiento.

importar glamoroso de 'glamoroso'

Título const = glamoroso.h1 ({
  fontFamily: 'Comic Sans MS',
  color azul'
})

Cualquiera que sea la sintaxis que use para describir sus estilos, ya no se limitarán a los componentes, sino que serán inseparables de ellos. Cuando se usa una biblioteca como React, los componentes son los bloques de construcción fundamentales, y ahora nuestros estilos forman una parte central de esa arquitectura. Si describimos todo en nuestra aplicación como componentes, ¿por qué no también nuestros estilos?

-

Para los veteranos experimentados de BEM, todo esto puede parecer una mejora relativamente superficial dada la importancia del cambio que hemos introducido en nuestro sistema. De hecho, los Módulos CSS le permiten lograr esto sin dejar la comodidad del ecosistema de herramientas CSS. Esta es la razón por la que tantos proyectos se quedan con los Módulos CSS, descubriendo que resuelve suficientemente la mayoría de sus problemas con la escritura de CSS a escala sin sacrificar la familiaridad del CSS regular.

Sin embargo, es cuando comenzamos a construir sobre estos conceptos básicos que las cosas comienzan a ser mucho más interesantes.

2)

CSS crítico

Se ha convertido en una práctica recomendada relativamente reciente incluir estilos críticos en el encabezado de su documento, mejorando los tiempos de carga iniciales al proporcionar solo los estilos necesarios para representar la página actual. Esto está en marcado contraste con la forma en que generalmente cargamos los estilos, lo que obliga al navegador a descargar todos los estilos visuales posibles para nuestra aplicación antes de que se muestre un solo píxel en la pantalla.

Si bien hay herramientas disponibles para extraer e incluir CSS críticos, como el crítico apropiadamente nombrado por Addy Osmani, no cambian fundamentalmente el hecho de que el CSS crítico es difícil de mantener y automatizar. Es una optimización de rendimiento engañosa, puramente opcional, por lo que la mayoría de los proyectos parecen olvidar este paso.

CSS-in-JS es una historia totalmente diferente.

Cuando se trabaja en una aplicación renderizada de servidor, extraer su CSS crítico no es simplemente una optimización: CSS-in-JS en el servidor requiere fundamentalmente CSS crítico para funcionar incluso en primer lugar.

Por ejemplo, cuando usa Afrodita de Khan Academy, realiza un seguimiento de los estilos que se usan dentro de un solo paso de renderizado usando su función css, que se llama en línea mientras aplica clases a sus elementos.

importar {StyleSheet, css} desde 'aphrodite'
const styles = StyleSheet.create ({
  título: {...}
})
rumbo const = ({children}) => (
  

{children}

)

Aunque todos sus estilos están definidos en JavaScript, puede extraer fácilmente todos los estilos de la página actual en una cadena estática de CSS que se puede insertar en el encabezado del documento al representar el lado del servidor.

importar {StyleSheetServer} desde 'aphrodite';

const {html, css} = StyleSheetServer.renderStatic (() => {
  return ReactDOMServer.renderToString ();
});

Ahora puede renderizar su bloque CSS crítico de esta manera:

const criticalCSS = `
  
    $ {css.content}
  
`;

Si ha examinado el modelo de representación del servidor de React, puede encontrar que este es un patrón muy familiar. En React, sus componentes definen su marcado en JavaScript, pero se pueden representar en una cadena HTML normal en el servidor.

Si crea su aplicación teniendo en cuenta la mejora progresiva, a pesar de estar escrita completamente en JavaScript, es posible que no requiera JavaScript en el cliente.

De cualquier manera, el paquete de JavaScript del lado del cliente incluye el código necesario para iniciar su aplicación de una sola página, de repente darle vida, renderizándose en el navegador a partir de ese momento.

Dado que la representación de su HTML y CSS en el servidor ocurre al mismo tiempo, las bibliotecas como Afrodita a menudo nos ayudan a simplificar la generación de CSS crítico y HTML generado por el servidor en una sola llamada, como vimos en el ejemplo anterior. Esto ahora nos permite renderizar nuestros componentes React a HTML estático de manera similar.

const appHtml = `
  
    $ {html}   
``

Al usar CSS-in-JS en el servidor, nuestra aplicación de una sola página no solo sigue funcionando sin JavaScript, sino que también puede funcionar más rápido.

Al igual que con el alcance de nuestros selectores, la mejor práctica de renderizar CSS crítico ahora está integrada, no habilitada.

3)

Optimizaciones más inteligentes

Recientemente hemos visto el surgimiento de nuevas formas de estructurar nuestro CSS, como Atomic CSS de Yahoo y Tachyons de Adam Morse, que evitan las "clases semánticas" en favor de clases pequeñas de un solo propósito. Por ejemplo, cuando usa CSS atómico, aplica clases con una sintaxis similar a una función que luego puede usarse para generar una hoja de estilo apropiada.

  CSS atómico

El objetivo es mantener su paquete CSS lo más ágil posible maximizando la reutilización de las clases, tratando efectivamente las clases como los estilos en línea. Si bien es fácil apreciar la reducción en el tamaño del archivo, los impactos tanto en su base de código como en los miembros de su equipo son cualquier cosa menos insignificantes. Estas optimizaciones, por su propia naturaleza, implican cambios tanto en su CSS como en su marcado, lo que los convierte en un esfuerzo arquitectónico más significativo.

Como ya hemos mencionado, cuando usa CSS-in-JS o Módulos CSS, ya no codifica cadenas de clase en su marcado, sino que usa referencias dinámicas a valores de JavaScript que han sido generados automáticamente por una biblioteca o herramienta de compilación.

En lugar de esto:

Escribimos esto:

Esto puede parecer un cambio bastante superficial, pero este es un cambio monumental en cómo manejamos la relación entre nuestro marcado y nuestros estilos. Al dar a nuestras herramientas CSS la capacidad de alterar no solo nuestros estilos, sino también las clases finales que aplicamos a nuestros elementos, desbloqueamos una clase completamente nueva de optimizaciones para nuestras hojas de estilo.

Si miramos el ejemplo anterior, "styles.sidebar" se evalúa como una cadena, pero no hay nada que lo limite a una sola clase. Por lo que sabemos, fácilmente podría terminar siendo una cadena de más de una docena de clases.

// Podría resolver fácilmente esto:

Si podemos optimizar nuestros estilos, generando múltiples clases para cada conjunto de estilos, podemos hacer algunas cosas realmente interesantes.

Mi ejemplo favorito de esto es Styletron por Ryan Tsao.

Styletron (Fuente)

De la misma manera que los módulos CSS-in-JS y CSS automatizan el proceso de agregar prefijos de clase de estilo BEM, Styletron hace lo mismo con la mentalidad Atomic CSS.

La API principal se centra en una única tarea: definir reglas CSS individuales para cada combinación de propiedad, valor y consulta de medios, que luego devuelve una clase generada automáticamente.

importar styletron desde 'styletron';
styletron.injectDeclaration ({
  utilería: 'color',
  val: 'rojo',
  medios: '(ancho mínimo: 800px)'
});
// → 'a'

Por supuesto, Styletron proporciona API de nivel superior, como su función injectStyle que permite definir múltiples reglas a la vez.

importar {injectStyle} desde 'styletron-utils';
injectStyle (styletron, {
  color rojo',
  display: 'bloque en línea'
});
// → 'a d'
injectStyle (styletron, {
  color rojo',
  fontSize: '1.6em'
});
// → 'a e'

Tome nota especial de la similitud entre los dos conjuntos de nombres de clase generados anteriormente.

Al renunciar al control de bajo nivel sobre las clases mismas, solo definiendo el conjunto deseado de estilos, permitimos que la biblioteca genere el conjunto óptimo de clases atómicas en nuestro nombre.

Comparación de tamaño de paquete CSS-in-JS usando los estilos de Airbnb (Fuente)

Las optimizaciones que generalmente se realizan a mano (encontrar la forma más eficiente de dividir nuestros estilos en clases reutilizables) ahora se pueden automatizar por completo. Puede estar empezando a notar una tendencia aquí. Atomic CSS está integrado, no habilitado.

4)

Gestión de paquetes

Antes de profundizar en este punto, primero vale la pena detenerse y hacerse una pregunta aparentemente simple.

¿Cómo compartimos CSS entre nosotros?

Hemos migrado desde la descarga manual de archivos CSS, hacia gestores de paquetes específicos front-end como Bower, y ahora a través de npm gracias a herramientas como Browserify y webpack. Aunque algunas herramientas han automatizado el proceso de incluir CSS desde paquetes externos, la comunidad de front-end se ha decidido principalmente por la inclusión manual de dependencias CSS.

De cualquier manera, hay una cosa en la que las dependencias CSS no son muy buenas, dependiendo de otras dependencias CSS.

Como muchos de ustedes recordarán, hemos visto un efecto similar con los módulos JavaScript entre Bower y npm.

Bower no estaba acoplado a ningún formato de módulo en particular, mientras que los módulos publicados en npm usan el formato de módulo CommonJS. Esto ha tenido un impacto masivo en la cantidad de paquetes publicados en cada plataforma.

Los árboles complejos de pequeñas dependencias anidadas se sentían como en casa en npm, mientras que Bower atraía grandes dependencias monolíticas, de las cuales solo podría tener dos o tres, más algunos complementos, por supuesto. Dado que sus dependencias no tenían un sistema de módulos en el que confiar, cada paquete no podía utilizar fácilmente sus propias dependencias, por lo que la integración siempre fue un paso manual para el consumidor.

Como resultado, el número de paquetes en npm a lo largo del tiempo forma una curva exponencial, mientras que Bower solo tuvo un aumento bastante lineal de paquetes. Si bien hay una variedad de razones para esta diferenciación, es justo decir que mucho tiene que ver con la forma en que cada plataforma permite (o no permite) que los paquetes dependan unos de otros en tiempo de ejecución.

Sí, es este gráfico nuevamente. (Fuente)

Desafortunadamente, esto parece demasiado familiar para la comunidad CSS, donde también hemos visto un aumento relativamente lento de paquetes monolíticos en comparación con lo que vemos con los paquetes de JavaScript en npm.

¿Qué pasaría si en cambio quisiéramos igualar el crecimiento exponencial de npm? ¿Qué pasaría si quisiéramos poder depender de jerarquías complejas de paquetes de diferentes tamaños, con menos enfoque en marcos grandes que lo abarquen todo? Para hacer esto, no solo necesitamos un administrador de paquetes que esté a la altura de la tarea, sino que también necesitamos un formato de módulo apropiado.

¿Esto significa que necesitamos un administrador de paquetes diseñado específicamente para CSS? ¿Para preprocesadores como Sass y Less?

Lo realmente interesante es que ya hemos pasado por una realización similar con HTML. Si hace las mismas preguntas sobre cómo compartimos el marcado entre nosotros, notará rápidamente que casi nunca compartimos HTML sin formato directamente: compartimos HTML en JS.

Hacemos esto a través de complementos jQuery, directivas angulares y componentes React. Componemos componentes grandes a partir de componentes más pequeños, cada uno con su propio HTML, cada uno publicado de forma independiente en npm. HTML como formato puede no ser lo suficientemente poderoso como para permitir esto, pero al incorporar HTML dentro de un lenguaje de programación completo, podemos evitar esta limitación fácilmente.

¿Qué pasa si, como HTML, compartimos nuestro CSS, y la lógica que lo genera, a través de JavaScript? ¿Qué pasa si, en lugar de usar mixins, usamos funciones que devuelven objetos y cadenas? En lugar de extender las clases, ¿qué sucede si simplemente fusionamos objetos con Object.assign o el nuevo operador de propagación de objetos?

const styles = {
  ...reglas,
  ... másReglas,
  fontFamily: 'Comic Sans MS',
  color azul'
}

Una vez que comenzamos a escribir nuestros estilos de esta manera, ahora podemos componer y compartir nuestro código de estilo como cualquier otro código en nuestra aplicación, usando los mismos patrones, las mismas herramientas, la misma infraestructura, el mismo ecosistema.

Un gran ejemplo de cómo esto comienza a dar sus frutos es en bibliotecas como Polished by Max Stoiber, Nik Graf y Brian Hough.

Pulido (fuente)

Polished es esencialmente el Lodash de CSS-in-JS, que proporciona un conjunto completo de mixins, funciones de color, shorthands y más, lo que hace que el proceso de creación de estilos en JavaScript sea mucho más familiar para aquellos que provienen de lenguajes como Sass. La diferencia clave ahora es que este código es mucho más componible, comprobable y compartible, capaz de utilizar el ecosistema completo de paquetes de JavaScript.

Entonces, cuando se trata de CSS, ¿cómo alcanzamos el mismo nivel de actividad de código abierto que se ve en npm en su conjunto, componiendo grandes colecciones de estilos de paquetes pequeños, reutilizables y de código abierto? Por extraño que parezca, podríamos lograr esto incorporando nuestro CSS en otro idioma y adoptando completamente los módulos de JavaScript.

5)

Estilo sin navegador

Hasta ahora, todos los puntos que hemos cubierto, aunque ciertamente son mucho más fáciles al escribir CSS en JavaScript, de ninguna manera son cosas que son imposibles con CSS normal. Es por eso que dejé el punto más interesante para el futuro hasta el final. Algo que, aunque no necesariamente desempeña un papel importante en la comunidad CSS-in-JS de hoy, es muy probable que se convierta en una capa fundamental en el futuro del diseño. Algo que afecta no solo a los desarrolladores, sino también a los diseñadores, que altera radicalmente la forma en que estas dos disciplinas se comunican entre sí.

Primero, para poner esto en contexto, debemos tomar un desvío rápido hacia React.

-

El modelo React se trata de componentes que representan representaciones intermedias de la salida final. Cuando trabajamos en el navegador, en lugar de mutar directamente elementos DOM, estamos construyendo árboles complejos de DOM virtual.

Sin embargo, lo interesante es que la representación al DOM no es parte de la biblioteca React central, sino que es proporcionada por react-dom.

importar {render} desde 'react-dom'

A pesar de que React se creó primero para el DOM, y todavía utiliza la mayor parte de su uso en ese entorno, este modelo permite que React apunte a entornos muy diferentes simplemente introduciendo nuevos renderizadores.

JSX no se trata solo de DOM virtual, sino de lo virtual.

Esto es lo que permite que React Native funcione, escribiendo aplicaciones verdaderamente nativas en JavaScript, escribiendo componentes que representan representaciones virtuales de sus contrapartes nativas. En lugar de div y span, tenemos Ver y Texto.

Desde una perspectiva CSS, lo más interesante de React Native es que viene con su propia API StyleSheet:

var styles = StyleSheet.create ({
  envase: {
    borderRadius: 4,
    borderWidth: 0.5,
    borderColor: '# d6d7da',
  },
  título: {
    fontSize: 19,
    fontWeight: 'negrita',
  },
  activeTitle: {
    color rojo',
  }
})

Aquí puede ver un conjunto familiar de estilos, en este caso que cubre colores, fuentes y estilo de borde.

Estas reglas son bastante sencillas y se asignan fácilmente a la mayoría de los entornos de interfaz de usuario, pero las cosas se ponen realmente interesantes cuando se trata del diseño nativo.

var styles = StyleSheet.create ({
  envase: {
    pantalla: 'flex'
  }
})

A pesar de estar fuera de un entorno de navegador, React Native se entrega con su propia implementación nativa de flexbox.

Inicialmente lanzado como un paquete de JavaScript llamado css-layout, reimplementando flexbox completamente en JavaScript (respaldado por un conjunto de pruebas apropiadamente completo), ahora se ha migrado a C para una mejor portabilidad.

Dado el alcance y la importancia del proyecto, se le ha dado una marca propia más significativa en forma de yoga.

Yoga (fuente)

A pesar de que Yoga se trata de portar conceptos de CSS a entornos que no son del navegador, el alcance potencialmente inmanejable se ha reiniciado al centrarse solo en un subconjunto de características de CSS.

"El enfoque del yoga es crear una biblioteca de diseño expresivo, no implementar todo el CSS"

Este tipo de compensaciones puede parecer limitante, pero cuando observa el historial de la arquitectura CSS, está claro que trabajar con CSS a escala se trata de elegir un subconjunto razonable del lenguaje.

En el caso del Yoga, evitan la cascada en favor de los estilos con alcance y centran su motor de diseño completamente en flexbox. Si bien esto excluye una gran cantidad de funcionalidades, también abre una oportunidad increíble para componentes multiplataforma con estilo incorporado, y ya hemos visto varios proyectos notables de código abierto que intentan capitalizar este hecho.

React Native for Web de Nicolas Gallagher pretende ser un reemplazo directo para la biblioteca react-native. Cuando se usa un paquete como webpack, el alias de paquetes de terceros es bastante sencillo.

módulo: {
  alias: {
    'react-native': 'react-native-web'
  }
}

El uso de React Native para Web permite que los componentes de React Native funcionen en un entorno de navegador, incluido un puerto de navegador de la API React Native StyleSheet.

Del mismo modo, reactivo-primitivos de Leland Richardson se trata de proporcionar un conjunto multiplataforma de componentes primitivos que abstraen los detalles de implementación de la plataforma objetivo, creando una línea base viable para componentes multiplataforma.

Incluso Microsoft está entrando en acción con la introducción de ReactXP, una biblioteca diseñada para agilizar los esfuerzos para compartir código tanto en la web como en la nativa, que también incluye su propia implementación de estilo independiente de la plataforma.

-

Incluso si no escribe software para aplicaciones nativas, es importante tener en cuenta que tener una abstracción de componentes verdaderamente multiplataforma nos permite apuntar a un conjunto de entornos efectivamente ilimitado, a veces de formas que nunca podría haber predicho.

El ejemplo más sorprendente de esto que he visto es react-sketchapp de Jon Gold en Airbnb.

react-sketchapp (fuente)

Para muchos de nosotros, pasamos gran parte de nuestro tiempo tratando de estandarizar nuestro lenguaje de diseño, limitando la cantidad de duplicación en nuestros sistemas tanto como sea posible. Desafortunadamente, por mucho que quisiéramos tener una sola fuente de verdad, parecía que lo mejor que podíamos esperar era reducirlo a dos: una guía de estilo de vida para desarrolladores y una guía de estilo estático para diseñadores. Aunque ciertamente es mucho mejor de lo que históricamente hemos estado acostumbrados, esto todavía nos deja sincronizar manualmente desde las herramientas de diseño, como Sketch, hasta el código y viceversa. Aquí es donde entra en juego react-sketchapp.

Gracias a la API JavaScript de Sketch y la capacidad de React de conectarse a diferentes renderizadores, react-sketchapp nos permite tomar nuestros componentes React multiplataforma y presentarlos en nuestros documentos de Sketch.

Ejemplo de tarjetas de perfil con tecnología de react-sketchapp (fuente)

No hace falta decir que esto tiene el potencial de sacudir masivamente la forma en que los diseñadores y desarrolladores colaboran. Ahora, cuando nos referimos a los mismos componentes mientras iteramos en nuestros diseños, también podemos referirnos a la misma implementación, independientemente de si estamos trabajando con herramientas para diseñadores o desarrolladores.

Con símbolos en Sketch y componentes en React, nuestra industria está esencialmente comenzando a converger en la misma abstracción, abriéndonos la oportunidad de trabajar juntos al compartir las mismas herramientas.

No es casualidad que muchos de estos nuevos experimentos provengan de la comunidad React y de las comunidades que la rodean.

En una arquitectura de componentes, co-ubicar tantas de las preocupaciones de un componente en un solo lugar se convierte en una alta prioridad. Esto, por supuesto, incluye sus estilos de ámbito local, pero incluso se extiende a áreas más complicadas como la obtención de datos gracias a bibliotecas como Relay y Apollo. El resultado es algo que desbloquea una enorme cantidad de potencial, del cual solo hemos arañado la superficie.

Si bien esto tiene un gran impacto en la forma en que diseñamos nuestras aplicaciones, tiene un efecto igualmente grande en todo lo demás en nuestra arquitectura, pero por una buena razón.

Al unificar nuestro modelo en torno a los componentes escritos en un solo idioma, tenemos el potencial de separar mejor nuestras preocupaciones, no por tecnología, sino por funcionalidad. Alcanzar todo alrededor de la unidad de un componente, escalar sistemas grandes pero mantenibles a partir de ellos, optimizados de formas que antes no eran posibles, compartir nuestro trabajo entre nosotros más fácilmente y componer aplicaciones grandes a partir de pequeños bloques de construcción de código abierto. Lo más importante es que podemos hacer todo esto sin romper la mejora progresiva, sin renunciar a los principios que muchos de nosotros vemos como una parte no negociable de tomar en serio la plataforma web.

Sobre todo, estoy entusiasmado con el potencial de los componentes escritos en un solo idioma para formar la base de un nuevo lenguaje de estilo unificado, uno que une a la comunidad de front-end de formas que nunca antes habíamos visto.

En SEEK, estamos trabajando para aprovechar esto construyendo nuestra propia guía de estilo de vida en torno a este modelo de componentes, donde la semántica, la interactividad y el estilo visual se unen bajo una sola abstracción. Esto forma un lenguaje de diseño común, compartido entre desarrolladores y diseñadores por igual.

En la medida de lo posible, crear una página debe ser tan simple como combinar un conjunto de componentes obstinados que aseguren que nuestro trabajo se mantenga en la marca, al tiempo que nos permite actualizar nuestro lenguaje de diseño mucho después de haber enviado a producción.

importar {
  PageBlock,
  Tarjeta,
  Texto
} de 'seek-style-guide / react'
const App = () => (
  
    
       ¡Hola mundo! 
    
  
)

A pesar de que nuestra guía de estilo está construida actualmente con React, paquete web y módulos CSS, la arquitectura refleja exactamente lo que encontraría en cualquier sistema construido con CSS-in-JS. Las opciones tecnológicas pueden diferir, pero la mentalidad es la misma.

Sin embargo, estas opciones tecnológicas probablemente tendrán que cambiar de manera inesperada en el futuro, por lo que vigilar este espacio es tan crítico para el desarrollo continuo de nuestro ecosistema componente. Es posible que hoy no estemos utilizando CSS-in-JS, pero es muy posible que surja una razón convincente para cambiar antes de lo que pensamos.

CSS-in-JS ha recorrido un camino sorprendentemente largo en un corto período de tiempo, pero es importante tener en cuenta que, en el gran esquema de las cosas, solo está comenzando.

Todavía hay mucho margen de mejora, y las innovaciones no muestran signos de detenerse. Las bibliotecas siguen apareciendo para abordar los problemas pendientes y mejorar la experiencia del desarrollador: mejoras de rendimiento, extracción de CSS estático en el momento de la compilación, focalización de variables CSS y reducción de la barrera de entrada para todos los desarrolladores front-end.

Aquí es donde entra la comunidad CSS. A pesar de todas estas alteraciones masivas en nuestro flujo de trabajo, nada de esto cambia el hecho de que aún necesita saber CSS.

Podemos expresarlo con una sintaxis diferente, podemos diseñar nuestras aplicaciones de diferentes maneras, pero los bloques de construcción fundamentales de CSS no van a desaparecer. Igualmente, el avance de nuestra industria hacia las arquitecturas de componentes es inevitable, y el deseo de reinventar el front-end a través de esta lente solo se está fortaleciendo. Existe una necesidad muy real de que trabajemos juntos, para garantizar que nuestras soluciones sean ampliamente aplicables a los desarrolladores de todos los orígenes, ya sea centrados en el diseño, en la ingeniería o en ambos.

Si bien a veces parecemos estar en desacuerdo, las comunidades CSS y JS comparten la pasión por mejorar el front-end, por tomar en serio la plataforma web y mejorar nuestros procesos para la próxima generación de sitios web. Hay mucho potencial aquí, y aunque hemos cubierto una cantidad increíble de terreno hasta ahora, todavía queda mucho trabajo por hacer.

En este punto, es posible que aún no estés convencido, y eso está totalmente bien. Es completamente razonable encontrar que CSS-in-JS no sea adecuado para su trabajo en este momento, pero espero que sea por las razones correctas, en lugar de objeciones superficiales a la mera sintaxis.

De todos modos, parece bastante probable que este enfoque de los estilos de autor solo se haga más popular en los próximos años, y vale la pena vigilarlo mientras este enfoque continúa evolucionando a un ritmo tan rápido. Espero sinceramente que pueda unirse a nosotros para ayudar a que la próxima generación de herramientas CSS sea lo más efectiva posible para todos los desarrolladores front-end, ya sea a través de contribuciones de código o simplemente siendo una parte activa de la conversación. Si no, al menos, espero haber podido darte una mejor comprensión de por qué la gente es tan apasionada por este espacio y, tal vez, por qué no es una idea tan ridícula después de todo.

Este artículo fue escrito en paralelo con una charla del mismo nombre, presentada en CSSconf EU 2017 en Berlín, Alemania, que ahora está disponible en YouTube.