Records anidados: el dolor de la profundidad y cómo no sufrirlo

Hay un momento previsible en la vida de todo el que aprende Elm, y suele llegar la primera semana. El modelo ha crecido, alguien ha agrupado unos cuantos campos en un record interno porque parecía lo ordenado, y entonces hace falta cambiar un valor que está dos o tres niveles más abajo. La sintaxis de actualización, tan elegante para un campo directo, resulta no tener ninguna versión profunda: no existe forma de nombrar una ruta de campos, no existe operador que descienda por el árbol y no existe biblioteca oficial de lentes que lo resuelva. Lo que hay es la obligación de reconstruir a mano cada record del camino, de fuera hacia dentro, en una expresión que se lee peor cuanto más útil es. La reacción natural es interpretarlo como una carencia del lenguaje y buscar la manera de rellenarla. La lectura fértil es otra: la incomodidad no es un accidente, es un termómetro. Elm hace fácil lo que quiere que hagas y difícil lo que sospecha que no deberías estar haciendo, y un modelo profundamente anidado casi siempre resulta ser un modelo que nadie ha revisado desde que empezó a crecer.

El dolor, escrito entero y sin adornos

Empecemos por ver el problema en su forma cruda. Un modelo con tres niveles y la necesidad de cambiar un valor del fondo produce esta expresión, que no es un ejemplo exagerado sino exactamente lo que hay que escribir.

type alias Modelo =
    { usuario : Usuario, tema : Tema }

type alias Usuario =
    { nombre : String, ajustes : Ajustes }

type alias Ajustes =
    { idioma : String, notificaciones : Notificaciones }

type alias Notificaciones =
    { correo : Bool, movil : Bool }

-- Cambiar un booleano del fondo obliga a reconstruir todo el camino
activarMovil : Modelo -> Modelo
activarMovil modelo =
    let
        u =
            modelo.usuario

        a =
            u.ajustes

        n =
            a.notificaciones
    in
    { modelo
        | usuario =
            { u
                | ajustes =
                    { a | notificaciones = { n | movil = True } }
            }
    }

Trece líneas para cambiar un booleano. Y lo peor no es la longitud sino la escala: cada campo profundo que la aplicación necesite modificar exige su propia versión de esta escalera, de modo que el coste total crece con el producto del número de niveles por el número de campos tocados. Además, la parte central es puro ruido estructural, idéntica en todas las funciones que toquen esa rama, y por tanto un lugar excelente para que se cuele un error de copia que el compilador no detectará si los tipos coinciden.

Aplanar: la cura que elimina el problema en vez de gestionarlo

La primera opción, y con diferencia la mejor cuando es viable, consiste en no tener el anidamiento. Muchos records internos existen por un impulso taxonómico y no por una necesidad real: agrupan campos que conceptualmente van juntos pero que la aplicación siempre trata por separado. Si nada consume el record interno como unidad, ese record no está aportando nada y sí está cobrando peaje en cada actualización.

-- Aplanado: los campos suben al modelo con nombres cualificados
type alias Modelo =
    { nombreUsuario : String
    , idioma : String
    , notificacionesCorreo : Bool
    , notificacionesMovil : Bool
    , tema : Tema
    }

-- La misma operacion de antes, ahora en una linea
activarMovil : Modelo -> Modelo
activarMovil modelo =
    { modelo | notificacionesMovil = True }

El criterio para decidir si un record interno merece existir es funcional, no estético: pregúntate si alguna función recibe ese record entero como argumento o lo devuelve como resultado. Si la respuesta es sí, el agrupamiento es real y tiene sentido; si nadie lo trata nunca como una unidad, es una carpeta vacía que solo sirve para alargar rutas. Conviene decirlo con claridad porque contradice un hábito muy arraigado: en Elm un modelo plano de quince campos suele ser mejor diseño que un modelo elegante de cuatro niveles.

flowchart TD
A[Actualizacion profunda] --> B{Se usa el record interno como unidad}
B -->|No| C[Aplanar el modelo]
B -->|Si| D[Funcion auxiliar por nivel]
C --> E[Una linea por cambio]
D --> F[Actualizadores componibles]
style C fill:#a6e3a1,color:#11111b
style D fill:#89b4fa,color:#11111b
style E fill:#a6e3a1,color:#11111b

Cuando la profundidad es real: auxiliares de un solo nivel

A veces el anidamiento está justificado. Ocurre cuando el record interno tiene identidad propia, viaja solo entre funciones, se decodifica como unidad o representa el estado de una página que se compone dentro de otra. En esos casos la solución no es aplanar sino encapsular: escribir para cada nivel una función que reciba un transformador del interior y devuelva un transformador del exterior. La forma canónica recibe una función, no un valor, y eso es justamente lo que la hace componible.

-- Un actualizador por nivel: recibe una funcion y devuelve otra
enUsuario : (Usuario -> Usuario) -> Modelo -> Modelo
enUsuario f modelo =
    { modelo | usuario = f modelo.usuario }

enAjustes : (Ajustes -> Ajustes) -> Usuario -> Usuario
enAjustes f u =
    { u | ajustes = f u.ajustes }

enNotificaciones : (Notificaciones -> Notificaciones) -> Ajustes -> Ajustes
enNotificaciones f a =
    { a | notificaciones = f a.notificaciones }

-- La composicion recorre el camino, y se lee de fuera hacia dentro
activarMovil : Modelo -> Modelo
activarMovil =
    enUsuario (enAjustes (enNotificaciones (\n -> { n | movil = True })))

-- Cada nivel se reutiliza para cualquier otro cambio de esa rama
cambiarIdioma : String -> Modelo -> Modelo
cambiarIdioma nuevo =
    enUsuario (enAjustes (\a -> { a | idioma = nuevo }))

La diferencia con la escalera manual es que el ruido estructural se escribe una sola vez por nivel y se reutiliza para siempre. Cada auxiliar es minúscula, obviamente correcta y comprobable por separado, y las combinaciones nuevas no cuestan nada. Esta es, de hecho, la forma artesanal de lo que otros ecosistemas empaquetan como lentes; la diferencia es que aquí se escribe en tres líneas por nivel y sin introducir ninguna abstracción que haya que aprender aparte. Cuando cada nivel corresponde además a un módulo con su propio modelo y su propio mensaje, la auxiliar se convierte en el punto natural donde ese módulo se integra en el padre.