La ruta dentro del Model: el estado de cada página y su nacimiento

Cuando una aplicación de una sola página empieza a crecer, el punto donde se decide si envejecerá bien o mal casi nunca es el enrutador: es la forma del modelo. La primera versión siempre es la misma y siempre parece razonable. Se guarda la ruta actual en un campo, y como la pantalla de artículos necesita una lista, se añade un campo para la lista; como la de detalle necesita un artículo, se añade otro; como el formulario necesita un borrador, otro más; y como todo eso se carga de forma asíncrona, se añaden banderas de carga y campos de error. Al cabo de unos meses el modelo tiene treinta campos de los cuales cinco tienen sentido a la vez, y nadie sabe ya cuáles porque la relación entre la ruta y los campos vivos no está escrita en ninguna parte: vive en la cabeza de quien lo escribió y en el orden en que se asignan los valores. El problema no es el desorden, es que el tipo miente. Declara un espacio de estados enormemente mayor que el de los estados legítimos, y todo lo que sobra es superficie donde se alojan los fallos. La corrección es la misma que ya conoces de los niveles de modelado, aplicada aquí: hacer que los estados inválidos no se puedan representar, con la ruta como índice y no como contenido.

La ruta identifica la pantalla; no es la pantalla

Conviene fijar la distinción con precisión porque de ella se sigue todo lo demás. Un Route es lo que la dirección aporta: qué pantalla y con qué identificadores. Es un dato pequeño, comparable, serializable y que siempre existe. El estado de una pantalla es otra cosa: incluye lo que se ha cargado, lo que está cargando, lo que ha fallado, lo que el usuario lleva escrito en un formulario y lo que tiene desplegado. Es un dato grande, distinto en cada pantalla, y que nace cuando se entra y muere cuando se sale. Confundirlos lleva al modelo plano; separarlos lleva a un modelo donde el estado vive dentro del constructor de la página a la que pertenece.

-- Modelo plano: casi ninguna combinacion es legitima
type alias ModelPlano =
    { ruta : Route
    , articulos : List Articulo
    , cargando : Bool
    , error : Maybe String
    , articuloActual : Maybe Articulo
    , borrador : String
    }


-- Modelo indexado: el estado vive dentro de su pantalla
type alias Model =
    { key : Nav.Key
    , sesion : Sesion
    , page : Page
    }


type Page
    = Inicio
    | Articulos (Estado (List Articulo))
    | Detalle Int (Estado Articulo)
    | Editor Borrador
    | NoEncontrado


type Estado a
    = Cargando
    | Cargado a
    | Fallo Error

Compara los dos espacios de estados. El modelo plano admite que haya un artículo actual y a la vez un borrador y a la vez un error, sin que ninguna pantalla lo pida; admite también estar cargando y tener error a la vez, y tener la lista llena mientras la bandera de carga sigue activa. Ninguno de esos estados significa nada, pero todos son construibles y por tanto todos hay que considerarlos al leer la vista. El modelo indexado no admite ninguno: si la página es de detalle, no existe ningún borrador porque no hay dónde ponerlo, y la carga y el fallo son constructores del mismo tipo y por tanto mutuamente excluyentes por construcción.

Entrar en una ruta es construir su estado

Con el modelo así, aparece de forma natural la función central de toda aplicación de una sola página: la que convierte un Route en la página correspondiente junto con el comando que carga lo que esa página necesita. Es una función pequeña, un case sobre la ruta, y tiene la virtud de reunir en un solo sitio la respuesta a la pregunta qué ocurre al entrar aquí. No hay que buscarla repartida entre manejadores de eventos ni ciclos de vida de componentes: está escrita entera, y el compilador obliga a completarla cada vez que se añade una ruta nueva.

entrar : Route -> Model -> ( Model, Cmd Msg )
entrar ruta model =
    case ruta of
        Route.Inicio ->
            ( { model | page = Inicio }, Cmd.none )

        Route.Articulos ->
            ( { model | page = Articulos Cargando }
            , Api.pedirArticulos RecibidosArticulos
            )

        Route.Articulo id ->
            ( { model | page = Detalle id Cargando }
            , Api.pedirArticulo id RecibidoArticulo
            )

        Route.NoEncontrado ->
            ( { model | page = NoEncontrado }, Cmd.none )


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        CambioDeUrl url ->
            entrar (Route.parse url) model

        _ ->
            ( model, Cmd.none )

Un matiz que ahorra disgustos: el estado inicial de una pantalla que carga datos debe ser Cargando, nunca una lista vacía. La diferencia parece cosmética y no lo es, porque la lista vacía significa que se consultó y no había nada, mientras que la carga significa que aún no se sabe, y la interfaz que corresponde a cada una es distinta. Confundirlas produce el parpadeo del mensaje de no hay resultados justo antes de que aparezcan los resultados, un defecto que delata que el modelo no distinguía dos situaciones que sí eran distintas.

flowchart TD
A[Cambio de Url] --> B[Route parse]
I[Init con la url inicial] --> B
B --> E[Funcion entrar]
E --> P[Page con estado Cargando]
E --> C[Cmd de carga]
C --> R[Mensaje con la respuesta]
R --> Q[Page con estado Cargado o Fallo]
P --> V[Vista de la pagina]
Q --> V
style E fill:#89b4fa,color:#11111b
style P fill:#f9e2af,color:#11111b
style Q fill:#a6e3a1,color:#11111b

Delegar sin fusionar

Cuando una pantalla crece hasta merecer su propio módulo, la delegación sigue el mismo patrón que ya conoces de la composición de la arquitectura: el módulo declara su Model, su Msg, su update y su view, y el programa principal envuelve. El constructor de la página guarda el modelo del submódulo, un constructor del mensaje principal envuelve los mensajes del submódulo, y en el punto de conexión se traducen las salidas con Cmd.map y las vistas con Html.map. Lo importante es que los vocabularios no se fusionan: el módulo de la pantalla nunca conoce el tipo de mensajes del programa, y por eso puede leerse, probarse y modificarse sin salir de su fichero.

update msg model =
    case ( msg, model.page ) of
        ( MsgEditor sub, Editor estadoEditor ) ->
            let
                ( nuevoEstado, cmdEditor ) =
                    Editor.update sub estadoEditor
            in
            ( { model | page = Editor nuevoEstado }
            , Cmd.map MsgEditor cmdEditor
            )

        ( MsgEditor _, _ ) ->
            ( model, Cmd.none )

        _ ->
            ( model, Cmd.none )