Combinar decodificadores: map2, map3 y el estilo pipeline

Hasta aquí cada decodificador extraía una cosa. Un modelo real no es una cosa: es un registro con nombre, correo, edad, fecha de alta y una lista de permisos, y todos esos valores tienen que salir del mismo documento en un solo acto. La tentación es imaginar que hará falta un mecanismo nuevo, alguna clase de constructor especial que sepa recorrer el objeto y rellenar campos. No hace falta nada de eso, y entender por qué es el paso que abre el nivel entero. En Elm, declarar un alias de registro define automáticamente una función que recibe los campos en orden y devuelve el registro; esa función es tan ordinaria como cualquier otra. El problema, entonces, deja de ser cómo construir un registro y pasa a ser otro mucho más general: cómo aplicar una función corriente a argumentos que aún no tengo, porque cada uno está encerrado dentro de un decodificador que todavía no se ha ejecutado. La respuesta a esa pregunta es map2, es map3, y cuando el registro crece es el estilo pipeline, que no es otra cosa que la misma respuesta escrita de forma que no se acabe nunca.

El constructor del registro ya es una función

Antes de combinar nada conviene ver la pieza que se va a combinar. Cuando defines un alias de registro con tres campos, el compilador te regala una función de tres argumentos que los recibe en el orden de declaración y devuelve el registro construido. No es un método, no es un inicializador especial y no vive en ningún espacio de nombres aparte: es un valor de función que puedes pasar, componer y aplicar parcialmente.

type alias Usuario =
    { nombre : String
    , edad : Int
    , activo : Bool
    }


-- El alias define esta funcion, sin escribirla
-- Usuario : String -> Int -> Bool -> Usuario


-- Y map2 aplica una funcion de dos argumentos a dos decodificadores
map2 : (a -> b -> valor) -> Decoder a -> Decoder b -> Decoder valor
map3 : (a -> b -> c -> valor) -> Decoder a -> Decoder b -> Decoder c -> Decoder valor

Lee la firma de map2 sustituyendo mentalmente los nombres por casos concretos y verás que no hay nada específico de JSON en ella. Dice: si me das una manera de combinar dos valores y dos planes para obtener esos valores, te devuelvo un plan para obtener la combinación. La misma forma aparece en Maybe, en Result, en las tareas y en las listas, y reconocerla aquí es reconocer un patrón que ya conoces de niveles anteriores aplicado a un contenedor nuevo.

Aridades fijas y el techo que imponen

Con dos o tres campos el resultado es limpio y perfectamente legible. El decodificador se lee como una declaración: este registro se construye con esta función a partir de estos tres campos, cada uno con su nombre y su tipo. Todo está a la vista y el compilador comprueba que la función y los decodificadores encajan en número y en tipo.

usuarioDecoder : Decoder Usuario
usuarioDecoder =
    map3 Usuario
        (field "nombre" string)
        (field "edad" int)
        (field "activo" bool)

El problema aparece cuando el registro crece, y crece siempre. La biblioteca ofrece variantes hasta ocho argumentos, así que un registro de doce campos simplemente no tiene función que lo cubra. Pero el límite duro no es lo peor: mucho antes de llegar a él, la correspondencia entre la posición del decodificador y el campo del registro se vuelve un ejercicio de contar con el dedo. Si dos campos contiguos son ambos cadenas y alguien los intercambia por descuido, el programa compila sin una queja y el usuario ve el correo donde debería ver el nombre. El sistema de tipos no puede protegerte ahí, porque desde su punto de vista ambas cosas son texto y el error es de significado, no de forma.

map: transformar el valor recién obtenido

Antes de pasar a la notación definitiva conviene rescatar el caso más simple de la familia, que es el de un solo decodificador. La función de un argumento aplica una transformación al valor extraído sin tocar el resto del plan, y su utilidad no es cosmética: es el sitio donde una cadena desnuda se convierte en un tipo del dominio y deja de poder confundirse con cualquier otra cadena. Combinada con los envoltorios de un solo constructor, resuelve de raíz el fallo silencioso de la sección anterior.

map : (a -> valor) -> Decoder a -> Decoder valor


-- Envoltorios del dominio: dos cadenas que ya no son intercambiables
type Correo
    = Correo String


type Nombre
    = Nombre String


correoDecoder : Decoder Correo
correoDecoder =
    map Correo (field "correo" string)

Con el registro definido sobre estos tipos, intercambiar dos decodificadores deja de compilar, porque un Correo y un Nombre ya no son la misma cosa para el compilador aunque ambos contengan texto. El coste es un constructor por concepto y una función para extraer el contenido cuando haga falta; el beneficio es que la comprobación posicional vuelve a ser una comprobación real y no una coincidencia de tipos primitivos.

El pipeline: saturar una función campo a campo

El estilo pipeline resuelve las dos cosas a la vez y lo hace sin ningún mecanismo nuevo, solo con aplicación parcial. La idea, una vez vista, resulta casi obvia. Se empieza con un decodificador que no mira el documento y siempre tiene éxito devolviendo la función constructora todavía sin aplicar. A partir de ahí, cada paso toma ese decodificador de función, extrae un campo del documento y aplica la función a lo extraído, devolviendo un decodificador de una función con un argumento menos. Cuando ya no quedan argumentos, lo que tienes es un decodificador del registro.

import Json.Decode.Pipeline exposing (hardcoded, optional, required)


-- Cada paso consume un argumento de la funcion constructora
-- required : String -> Decoder a -> Decoder (a -> b) -> Decoder b


usuarioDecoder : Decoder Usuario
usuarioDecoder =
    succeed Usuario
        |> required "nombre" string
        |> required "edad" int
        |> optional "activo" bool True

Detente en la firma de required, porque es la única cosa realmente nueva de la lección. Su último parámetro es un decodificador cuyo contenido es una función pendiente de un argumento, y su retorno es un decodificador de lo que esa función devuelve una vez alimentada. Encadenar es, literalmente, ir descontando parámetros. El primer paso parte de una función de tres argumentos, el segundo trabaja sobre una de dos, el tercero sobre una de uno, y el último produce el registro. Si sobra o falta un paso, el tipo final no será el registro y el compilador lo dirá con precisión.

flowchart LR
S[succeed Usuario funcion de tres] --> A[required nombre]
A --> B[funcion de dos]
B --> C[required edad]
C --> D[funcion de uno]
D --> E[optional activo]
E --> F[Decoder Usuario]
style S fill:#89b4fa,color:#11111b
style F fill:#a6e3a1,color:#11111b