CSS clásico en Elm: clases, hojas externas y el precio de la cadena de texto

Hay un momento incómodo en la vida de todo programador que llega a Elm desde otro ecosistema, y ocurre casi siempre el mismo día: acaba de descubrir que el compilador no le deja escribir un programa que rompa en ejecución, que los estados imposibles se pueden hacer irrepresentables y que refactorizar es una operación mecánica y segura, y entonces necesita poner un botón en azul. Escribe un atributo de clase, pone entre comillas el nombre que eligió en su hoja de estilos, compila, y todo va bien. Escribe mal el nombre, compila, y todo sigue yendo bien: el programa arranca, la vista se dibuja, no hay ningún error en ninguna parte, y el botón simplemente no está azul. Esa asimetría no es un descuido del diseño ni una carencia que alguien vaya a corregir en la próxima versión. Es la consecuencia exacta de que el estilo, en la web, viva en un lenguaje distinto, con su propio archivo, su propia gramática y su propio momento de evaluación, y de que el único puente entre ese lenguaje y el nuestro sea una cadena de texto que ningún compilador de este mundo puede verificar. Entender bien ese punto es lo que permite decidir después, con criterio y no por moda, si conviene quedarse en él.

Tres puertas y ninguna de ellas es tipada

El módulo Html.Attributes ofrece esencialmente tres caminos hacia el aspecto de un nodo. El primero es class, que recibe una cadena y la deposita literalmente en el atributo correspondiente del elemento. El segundo es classList, que recibe una lista de pares de cadena y booleano y añade solo aquellas clases cuya condición sea verdadera, lo cual convierte la variación de aspecto en una función del modelo sin necesidad de concatenar textos a mano. El tercero es style, que recibe una propiedad y un valor y produce una declaración en línea sobre el propio nodo, saltándose la hoja externa por completo. Los tres tienen la misma propiedad esencial y conviene enunciarla sin rodeos: sus argumentos son String, y por tanto el sistema de tipos no distingue un nombre de clase existente de uno inventado, ni una propiedad válida de una errata.

import Html exposing (button, div, text)
import Html.Attributes exposing (class, classList, style)


verBoton : Bool -> Html msg
verBoton activo =
    button
        [ classList
            [ ( "boton", True )
            , ( "boton--activo", activo )
            , ( "boton--inactivo", not activo )
            ]
        ]
        [ text "Guardar" ]


verAviso : Html msg
verAviso =
    div
        [ class "aviso"
        , style "padding" "1rem"
        , style "border-left" "3px solid tomato"
        ]
        [ text "Revisa los datos" ]

La diferencia entre classList y la concatenación manual de cadenas merece un apunte, porque es el único punto de esta historia donde el lenguaje aporta algo. Al expresar la condición como un booleano dentro de la estructura, la lógica de variación queda escrita en Elm y no en una plantilla de texto: se puede extraer a una función, se puede probar, se puede derivar de un tipo unión con exhaustividad garantizada. Lo que sigue sin garantizarse es que las cadenas de la izquierda correspondan con algo que exista realmente en la hoja de estilos, y esa es exactamente la mitad del problema que nos ocupa.

.boton {
  padding: 0.5rem 1rem;
  border-radius: 4px;
  border: none;
  font: inherit;
}

.boton--activo {
  background: #89b4fa;
  color: #11111b;
}

.boton--inactivo {
  background: #45475a;
  color: #a6adc8;
  cursor: not-allowed;
}

La hoja externa vive donde el compilador no mira

Conviene tener presente el mapa completo del sistema para entender por qué esto no puede ser de otro modo. El compilador de Elm lee archivos con extensión propia, construye un grafo de módulos, comprueba tipos, elimina el código no alcanzable y emite un artefacto de JavaScript. La hoja de estilos no forma parte de ese grafo en ningún momento: la carga el documento anfitrión mediante un enlace en la cabecera, o la inyecta un empaquetador ajeno, y llega al navegador por un camino paralelo. Cuando el programa arranca, el motor de estilos del navegador aplica las reglas al árbol que Elm produjo, resolviendo por nombre y sin que nadie haya comprobado nunca que los dos lados hablen del mismo vocabulario.

De esa separación se derivan consecuencias muy concretas, y todas comparten una firma reconocible: el fallo no se manifiesta como un error sino como una ausencia. Renombrar una clase en el CSS no rompe ninguna compilación, simplemente deja huérfanos todos los nodos que la citaban. Borrar una regla que ya nadie usa exige buscar la cadena por todo el proyecto y confiar en que nadie la construyó por concatenación. La eliminación de código muerto que Elm practica con tanto rigor sobre las funciones no alcanza jamás a una regla de estilo, de modo que las hojas crecen monótonamente y nadie se atreve a podarlas. Y la cascada, que es global por diseño, permite que una regla escrita en otro archivo por otra persona altere el aspecto de un componente sin que exista ninguna relación visible entre ambos.

Acotar el daño sin cambiar de enfoque

La comunidad no ha ignorado el problema, y ha producido un repertorio de disciplinas que conviene conocer porque son baratas y sirven de mucho. La más rentable de todas es también la más simple: no escribir nunca un nombre de clase en línea dentro de una vista, sino declararlo una sola vez en un módulo dedicado y referirse siempre a esa constante. La errata deja entonces de ser una cadena mal tecleada para convertirse en un nombre no definido, que es exactamente el tipo de error que el compilador de Elm sabe atrapar y explicar. La técnica no verifica que la regla exista en el CSS, pero elimina de golpe la clase entera de fallos por divergencia entre dos apariciones del mismo nombre.

module Estilos exposing (boton, botonActivo, tarjeta)


boton : String
boton =
    "boton"


botonActivo : String
botonActivo =
    "boton--activo"


tarjeta : String
tarjeta =
    "tarjeta"

La segunda disciplina consiste en reducir el espacio de nombres a un catálogo finito y ajeno, que es lo que en el fondo propone el enfoque de utilidades atómicas: si nadie inventa clases nuevas y todas provienen de un vocabulario publicado, la probabilidad de citar una inexistente baja mucho y la hoja deja de crecer. La tercera es procedimental: purgar periódicamente con herramientas que cruzan el texto del fuente con las reglas declaradas, aceptando que cualquier nombre construido dinámicamente quedará fuera de su alcance. Ninguna de las tres cambia el hecho fundamental, que conviene enunciar con claridad para no engañarse: entre el programa y su aspecto sigue habiendo una frontera de texto sin tipar, y todo lo que hacemos es reducir la superficie de esa frontera, no eliminarla.

flowchart LR
A[Fuente Elm] --> B[Compilador]
B --> C[Artefacto JavaScript]
D[Hoja de estilos] --> E[Anfitrion HTML]
C --> F[Arbol del documento]
E --> G[Motor de estilos]
F --> G
G --> H[Aspecto final]
style B fill:#a6e3a1,color:#11111b
style D fill:#f38ba8,color:#11111b
style G fill:#cba6f7,color:#11111b