Elm no tiene componentes: por qué la comunidad lo desaconseja

Hay una diferencia importante entre una tecnología que carece de una funcionalidad y una tecnología que la ha rechazado después de examinarla. Elm está en el segundo caso. Durante sus primeras versiones circularon tutoriales que mostraban cómo anidar unidades de estado unas dentro de otras, y la comunidad los leyó, con toda naturalidad, como el equivalente elmiano de un componente: un ejemplo canónico que había que imitar en cuanto la aplicación pasara de un contador. El resultado fue una generación de bases de código con jerarquías profundas de estado, cascadas de mensajes que subían y bajaban por niveles intermedios que no hacían nada con ellos, y una sensación general de estar peleando contra el lenguaje. La reacción no fue añadir azúcar sintáctico para abaratar ese anidamiento, sino retirar los ejemplos y explicar por qué la analogía era falsa desde el principio. Entender ese giro es entender algo más profundo que una convención de estilo: es entender que la modularidad de una aplicación puede descansar en funciones y módulos en lugar de descansar en objetos con estado propio, y que esa elección tiene consecuencias medibles sobre lo que cuesta cambiar el programa dentro de dos años.

La palabra esconde cuatro necesidades distintas

Cuando alguien pide un componente rara vez pide una sola cosa. Está pidiendo, mezcladas, cuatro necesidades que en los ecosistemas de objetos vienen empaquetadas de fábrica y que conviene separar antes de discutir nada. La primera es reutilizar apariencia: quiere escribir una tarjeta una vez y usarla en once pantallas. La segunda es guardar estado que solo importa dentro de un fragmento, como si un desplegable está abierto. La tercera es encapsular, es decir, impedir que el resto del programa manipule por dentro algo que debería ser opaco. La cuarta es tener una unidad de organización, un lugar donde poner el archivo. En un modelo de componentes las cuatro se resuelven con la misma construcción, y por eso parecen una sola.

En Elm las cuatro existen, pero cada una tiene su propia herramienta, y la potencia del diseño está justamente en que no comparten mecanismo. Reutilizar apariencia es escribir una función que devuelve Html msg, sin ceremonia ni registro. Encapsular es declarar un módulo que expone un tipo sin sus constructores y las funciones que lo manipulan, de modo que nadie de fuera pueda construir un valor inválido. Organizar es crear un archivo, porque en Elm un módulo es un archivo y nada más. Y guardar estado es añadir un campo al modelo, en el nivel donde ese estado tenga sentido. Ninguna de las cuatro necesita a las otras tres, así que reutilizar una vista no obliga a darle estado, y darle estado a algo no obliga a inventarle un ciclo de vida.

La separación se aprecia mejor cuando se escribe una misma pieza con las cuatro herramientas puestas una al lado de otra. Lo que en un modelo de componentes sería un solo archivo con una clase, un estado interno, un método de dibujo y una interfaz de propiedades, aquí se descompone en cosas que no se parecen entre sí y que se pueden adoptar por separado: puedes tener la función sin el módulo, el módulo sin el campo en el modelo, y el campo sin nada más. Esa independencia es lo que hace que el coste de cada decisión sea proporcional a lo que realmente necesitas, en vez de venir en un paquete indivisible.

-- Reutilizar apariencia: una funcion, nada mas
verPrecio : Centimos -> Html msg


-- Encapsular: un modulo que no deja construir un valor invalido
module Centimos exposing (Centimos, deEntero, aTexto)


-- Guardar estado: un campo y sus mensajes, en el nivel que corresponda
type alias Model =
    { cesta : Cesta, cuponAbierto : Bool }

Por qué el bucle no admite islas autónomas

La arquitectura de Elm tiene una propiedad que suele enunciarse como eslogan y que en realidad es una restricción técnica dura: existe un solo estado, un solo punto donde ese estado cambia y una sola descripción de la interfaz derivada de él. De ahí salen las garantías que hacen atractivo al lenguaje. El depurador puede reconstruir cualquier instante de la sesión porque tiene la lista completa de mensajes y una función pura que los aplica. El compilador puede exigir exhaustividad al tratar los mensajes porque el vocabulario está cerrado. Una prueba puede ejercitar toda la lógica sin montar un entorno de ejecución porque update no depende de nada externo. Un componente con estado propio, entendido como un nodo del árbol de vista que guarda información que el modelo no conoce, rompe las tres a la vez: hay estado fuera del modelo, hay cambios fuera de update y hay historia que el registro de mensajes no contiene.

Merece la pena insistir en que esta no es una objeción de pureza doctrinal. La consecuencia práctica de tener estado fuera del modelo es concreta y se paga a diario: un fallo reportado por un usuario deja de ser reproducible a partir de la secuencia de mensajes, porque falta información que solo existía dentro de un nodo del árbol; una prueba de un flujo completo necesita simular interacciones en lugar de aplicar mensajes; y la respuesta a la pregunta de por qué la pantalla muestra esto pasa a depender de un historial invisible. Todo lo que hace agradable depurar una aplicación en Elm descansa en que esa información no exista en ningún otro sitio.

Se puede, desde luego, anidar unidades completas de la arquitectura: un submódulo con su propio Model, su propio Msg y su propio update, embebido en el padre. Eso no rompe ninguna garantía, porque el estado del hijo sigue estando dentro del estado del padre y sus mensajes siguen pasando por el bucle. Lo que ocurre es que se paga, y el precio se ve mejor escrito que explicado.

-- El coste fijo de cada nivel de anidamiento
type alias Model =
    { buscador : Buscador.Model }


type Msg
    = BuscadorMsg Buscador.Msg


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        BuscadorMsg sub ->
            let
                ( nuevo, cmd ) =
                    Buscador.update sub model.buscador
            in
            ( { model | buscador = nuevo }, Cmd.map BuscadorMsg cmd )

Ese bloque no aporta lógica de negocio: es puro trámite de transporte, y se repite entero en cada nivel de la jerarquía y por cada hijo. Con dos niveles resulta tolerable; con cinco, un mensaje del usuario atraviesa cuatro funciones que no hacen nada con él salvo desenvolverlo y volverlo a envolver. Peor aún es el problema de la comunicación lateral: si el hijo necesita avisar al padre de algo, no basta con devolver un modelo y un comando, hay que inventar un canal adicional, y si dos hermanos deben coordinarse, el mensaje sube hasta el ancestro común y vuelve a bajar. Ninguna de esas dificultades es un fallo de Elm; son la consecuencia inevitable de haber trazado una frontera de estado donde los datos no la tenían.

Lo que se propone en su lugar

Queda entonces la pregunta legítima de qué hace uno en su lugar cuando la aplicación crece y el archivo principal supera las mil líneas. La respuesta oficial existe, está escrita y es menos espectacular de lo que la gente espera, lo cual explica en parte por qué se ignora tan a menudo.

La recomendación de la comunidad, formulada con más insistencia por Evan Czaplicki en su charla sobre la vida de un archivo y recogida después en el capítulo de escalado de la guía oficial, se resume en una inversión del orden habitual. En vez de empezar decidiendo las unidades y repartir el código entre ellas, se empieza con un archivo grande y se deja que las fronteras aparezcan por sí solas cuando el código lleve tiempo suficiente estabilizado como para que sean visibles. Cuando aparecen, casi nunca coinciden con fragmentos de pantalla: coinciden con conceptos del dominio, con estructuras de datos que tienen invariantes que proteger, con procesos que tienen estados legítimos y transiciones. El módulo que emerge de ahí no expone un ciclo de vida, expone un tipo y las operaciones que lo respetan.

-- Frontera por dominio: un tipo opaco y su vocabulario
module Cesta exposing (Cesta, vacia, agregar, total, articulos)


type Cesta
    = Cesta (List Linea)


agregar : Producto -> Int -> Cesta -> Cesta
agregar producto cantidad (Cesta lineas) =
    Cesta (fusionar producto cantidad lineas)


-- La vista es otra cosa, y es solo una funcion
verCesta : Cesta -> Html msg
verCesta cesta =
    ul [] (List.map verLinea (Cesta.articulos cesta))

Hay un dato histórico que ilumina esta recomendación mejor que cualquier argumento. Los ejemplos anidados que circulaban en los primeros años no se retiraron porque estuvieran mal escritos ni porque el patrón fallara técnicamente: se retiraron porque la comunidad observó, proyecto tras proyecto, que quien los leía los interpretaba como una plantilla que había que aplicar por defecto en lugar de como una técnica para un caso raro. Es un fenómeno conocido en la enseñanza de cualquier disciplina: un ejemplo canónico no transmite solo su contenido, transmite también la sugerencia de que eso es lo normal. Y como el patrón anidado se parecía a lo que la gente ya conocía de otros ecosistemas, encontraba menos resistencia que la alternativa, que exige desaprender antes de aprender. La retirada de los ejemplos fue, en ese sentido, una decisión pedagógica, no técnica.

Nótese lo que ha desaparecido. No hay que decidir si la cesta es un componente de presentación o de contenedor, ni cómo notifica a su padre, ni qué ocurre cuando se monta y se desmonta. Hay un tipo que nadie puede construir mal, un puñado de funciones puras que lo transforman y, separadamente, una función que lo dibuja. La reutilización está en las funciones, la protección está en la lista de exportación del módulo y el estado está donde siempre estuvo, en el modelo. Queda todavía un caso legítimo de submódulo con estado, y existe: lo estudiaremos en la lección siguiente, junto con el criterio para reconocerlo, porque negarlo del todo sería tan dogmático como usarlo en todas partes.

flowchart TD
P[Peticion de un componente] --> R[Reutilizar apariencia]
P --> E[Encapsular invariantes]
P --> O[Organizar archivos]
P --> S[Guardar estado]
R --> F[Funcion que devuelve Html]
E --> M[Modulo con tipo opaco]
O --> A[Un archivo por modulo]
S --> D[Campo en el modelo raiz]
style P fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b
style M fill:#89b4fa,color:#11111b
style D fill:#cba6f7,color:#11111b