El Model como record: modelar el estado y decidir qué entra en él

La Arquitectura Elm impone una condición que en cualquier otro ecosistema sonaría a restricción insoportable: todo el estado de la aplicación vive en un único valor. No hay estado local escondido en un componente, no hay variables de módulo que recuerden cosas entre llamadas, no hay caché invisible ni referencia mutable a la que alguien pueda escribir desde otro archivo. Si el programa necesita recordar algo, ese algo está en el modelo, y el modelo es un valor que puedes imprimir entero, comparar entero y guardar entero. Ese valor es, en la práctica totalidad de los casos, un record: la estructura que este nivel viene estudiando, ahora en su papel más importante. Y aquí es donde el record deja de ser una cuestión de sintaxis para convertirse en una cuestión de diseño, porque decidir qué campos tiene el modelo es decidir qué puede saber la aplicación, qué puede mostrar y, sobre todo, qué situaciones absurdas será capaz de representar sin que nadie se lo impida. Un modelo mal escogido no produce errores de compilación: produce una vida entera de comprobaciones defensivas escritas para desmentir estados que nunca deberían haber existido.

Un solo valor para todo lo que la aplicación sabe

El modelo se declara como cualquier otro alias de record y suele acompañarse de una función que produce su valor inicial. Lo relevante no es la sintaxis, que ya conocemos, sino el compromiso que implica: cualquier cosa que la interfaz necesite mostrar tiene que poder deducirse de este valor, y cualquier cosa que el usuario cambie tiene que acabar reflejada aquí.

type alias Model =
    { textoBusqueda : String
    , usuarios : List Usuario
    , seleccionado : Maybe Int
    , cargando : Bool
    , error : Maybe String
    }

init : () -> ( Model, Cmd Msg )
init _ =
    ( { textoBusqueda = ""
      , usuarios = []
      , seleccionado = Nothing
      , cargando = False
      , error = Nothing
      }
    , Cmd.none
    )

Este modelo funciona, y es el que casi todo el mundo escribe la primera vez. También es, como veremos en la tercera sección, un modelo defectuoso por razones que no tienen nada que ver con la sintaxis. Antes de llegar ahí conviene fijar la ventaja de la concentración: como el estado es un solo valor, la pregunta cuál es el estado de la aplicación en este instante tiene una respuesta literal y completa. No hay que reunir fragmentos dispersos por veinte componentes ni preguntarse si alguno guarda una copia desactualizada, y por eso serializar el estado, restaurarlo o reproducir un fallo exacto son operaciones triviales.

Esencial contra derivable: no guardes lo que puedes calcular

La segunda decisión importante es distinguir entre los datos que constituyen el estado y los que son función de él. Si un valor puede obtenerse a partir de otros campos, guardarlo es crear una segunda fuente de verdad que hay que mantener sincronizada en cada actualización, y toda desincronización posible acabará ocurriendo.

-- Mal: total y visibles son derivables de usuarios y textoBusqueda
type alias ModelRedundante =
    { usuarios : List Usuario
    , textoBusqueda : String
    , total : Int
    , visibles : List Usuario
    }

-- Bien: solo lo esencial en el modelo, lo demas se calcula en view
type alias ModelMinimo =
    { usuarios : List Usuario
    , textoBusqueda : String
    }

visibles : ModelMinimo -> List Usuario
visibles m =
    List.filter (\u -> String.contains m.textoBusqueda u.nombre) m.usuarios

total : ModelMinimo -> Int
total m =
    List.length m.usuarios

La versión redundante obliga a recalcular dos campos en cada rama de update que toque la lista o el texto, y basta con olvidar uno para que la interfaz mienta. La versión mínima no puede desincronizarse porque no hay nada que sincronizar: la función se evalúa cuando se necesita y siempre refleja el estado actual. La excepción legítima aparece cuando el cálculo es genuinamente costoso y se repite en cada fotograma, pero esa excepción hay que ganársela con una medición, no suponerla.

flowchart TD
M[Model esencial] --> D1[Funcion visibles]
M --> D2[Funcion total]
D1 --> V[View]
D2 --> V
R[Campo derivado guardado] --> S[Riesgo de desincronizacion]
style M fill:#a6e3a1,color:#11111b
style S fill:#f38ba8,color:#11111b
style V fill:#89b4fa,color:#11111b

Cuando el producto miente: estrechar el modelo

Volvamos al primer modelo de la lección. Tiene un booleano de carga, una lista de usuarios y un error opcional, tres campos que en apariencia describen tres aspectos independientes. No lo son en absoluto, y el número de combinaciones lo delata: si multiplicamos las posibilidades de cada campo obtenemos un espacio enorme de estados, de los cuales apenas cuatro tienen sentido. Cargando y con error a la vez no significa nada. Con lista llena y cargando activo tampoco. El record, por ser un producto, permite todas.

-- Los tres campos correlacionados desaparecen en un solo tipo
type EstadoUsuarios
    = NoSolicitado
    | Cargando
    | Fallo String
    | Cargados (List Usuario)

type alias Model =
    { textoBusqueda : String
    , usuarios : EstadoUsuarios
    , seleccionado : Maybe Int
    }

-- La vista ya no puede olvidarse de un caso: el compilador lo exige
verLista : Model -> Html Msg
verLista m =
    case m.usuarios of
        NoSolicitado ->
            text "Escribe algo para buscar"

        Cargando ->
            text "Cargando"

        Fallo motivo ->
            text ("Ha fallado: " ++ motivo)

        Cargados lista ->
            ul [] (List.map verUsuario lista)

El cambio es pequeño en líneas y enorme en garantías. Han desaparecido tres campos y con ellos todas sus combinaciones ilegales; ha desaparecido la necesidad de comprobar el booleano antes de mirar el error; y ha aparecido una obligación nueva que resulta ser un regalo, porque el case of exhaustivo fuerza a la vista a decidir qué mostrar en cada situación real. El criterio general que se extrae de aquí es el que gobierna todo el diseño de modelos en Elm: cuando dos o más campos solo tienen sentido en ciertas combinaciones, esos campos son en realidad un solo dato con varias formas, y ese dato pide un custom type.