Flags: la configuración inicial que entrega el anfitrión

Toda aplicación empieza con una pregunta que ella sola no puede responder: en qué circunstancias estoy arrancando. La dirección del servidor cambia entre desarrollo y producción, el idioma depende del navegador, la sesión depende de una cookie que Elm no puede leer, y el estado de la visita anterior vive en un almacenamiento al que solo el anfitrión tiene acceso. Nada de eso puede llegar por un port de entrada, y la razón es de orden temporal antes que de diseño: los ports de entrada producen suscripciones, las suscripciones se derivan del modelo, y en el instante del arranque el modelo todavía no existe. Los flags resuelven ese problema de arranque con la única solución compatible con la arquitectura: convertir la configuración en un argumento de init, entregado por el anfitrión en el mismo acto de inicializar la aplicación.

init cambia de firma y el programa cambia con él

Un programa sin configuración externa declara su función de arranque con un parámetro vacío, que representa la ausencia de datos de entrada. Al pasar a la variante con flags, ese parámetro pasa a tener el tipo de lo que el anfitrión promete entregar, y esa promesa aparece además en el tipo del programa completo. La consecuencia es que la configuración deja de ser una variable global consultada desde cualquier parte y se convierte en un argumento explícito que solo init recibe y que, a partir de ahí, viaja dentro del modelo si hace falta conservarlo.

-- Sin configuración externa: el parámetro es la unidad
main : Program () Model Msg
main =
    Browser.element
        { init = \_ -> ( modeloInicial, Cmd.none )
        , update = update
        , view = view
        , subscriptions = subscriptions
        }


-- Con flags: el tipo del programa declara qué espera de fuera
main : Program Json.Decode.Value Model Msg
main =
    Browser.element
        { init = init
        , update = update
        , view = view
        , subscriptions = subscriptions
        }

Del lado del anfitrión, la entrega ocurre en la misma llamada que monta la aplicación. El objeto que se pasa como configuración inicial se convierte en el argumento que recibe init, y esa conversión sucede antes de que exista la primera versión del modelo, antes del primer renderizado y antes de que se evalúe subscriptions por primera vez.

const guardado = localStorage.getItem("estado");

Elm.Main.init({
  node: document.getElementById("raiz"),
  flags: {
    api: "https://api.ejemplo.test",
    idioma: navigator.language,
    estadoPrevio: guardado ? JSON.parse(guardado) : null,
    ahora: Date.now(),
  },
});

Value en lugar de un record concreto

Elm permite declarar los flags con un tipo concreto, por ejemplo un record con los campos que esperas. Cuando lo haces, el runtime intenta convertir lo que el anfitrión entregó a ese tipo y, si no encaja, aborta el arranque con un error en la consola del navegador. La aplicación no se monta y el usuario ve una página vacía. Ese comportamiento es honesto pero brutal, y en producción rara vez es lo que quieres: un campo opcional ausente, una versión antigua del estado guardado o un valor nulo donde esperabas un número bastan para dejar la pantalla en blanco.

type alias Config =
    { api : String, idioma : String, ahora : Int }


decodificador : Json.Decode.Decoder Config
decodificador =
    Json.Decode.map3 Config
        (Json.Decode.field "api" Json.Decode.string)
        (Json.Decode.field "idioma" Json.Decode.string)
        (Json.Decode.field "ahora" Json.Decode.int)


init : Json.Decode.Value -> ( Model, Cmd Msg )
init crudo =
    case Json.Decode.decodeValue decodificador crudo of
        Ok config ->
            ( arranqueNormal config, cargarDatos config.api )

        Err error ->
            -- Arranque degradado: la aplicación existe y explica qué pasó
            ( arranqueDegradado (Json.Decode.errorToString error), Cmd.none )

La diferencia entre las dos ramas no es cosmética. En la primera, la aplicación arranca con una configuración verificada y el resto del programa puede confiar en ella sin volver a preguntarse por su forma. En la segunda, la aplicación existe igualmente, muestra un estado que explica el problema y conserva la capacidad de reaccionar. Un usuario que ve un mensaje claro está en una situación radicalmente mejor que uno que ve una página en blanco, y un desarrollador que recibe un informe con ese mensaje diagnostica en minutos lo que de otro modo llevaría horas.

flowchart TD
A[anfitrion prepara los flags] --> B[Elm init con flags]
B --> C[runtime entrega el Value a init]
C --> D{decodifica bien}
D -->|Ok| E[Model completo y Cmd inicial]
D -->|Err| F[Model degradado que explica el fallo]
E --> G[primera vista]
F --> G
style C fill:#f9e2af,color:#11111b
style E fill:#a6e3a1,color:#11111b
style F fill:#fab387,color:#11111b

Qué merece ser flag y qué merece ser port

La regla que ordena la decisión es temporal y no admite mucha discusión: si el dato debe estar disponible para construir la primera versión del modelo, es un flag; si puede llegar después, es un port de entrada. Los identificadores de sesión, la dirección de la interfaz remota, el idioma detectado, las banderas de funcionalidad y el estado restaurado de la visita anterior pertenecen al primer grupo. Los mensajes de un websocket, los cambios de conectividad, las notificaciones del sistema y las respuestas a operaciones que la aplicación inició pertenecen al segundo.

Una prueba práctica ayuda a resolver los casos límite: pregúntate qué debería ocurrir si ese dato cambiara mientras la aplicación está en marcha. Si la respuesta es que nada, porque el valor pertenece al contexto fijo de esta ejecución, es un flag. Si la respuesta es que la interfaz debería reaccionar, entonces el dato no es configuración sino estado del mundo, y la configuración inicial solo puede aportar su primera fotografía.

Hay un caso que confunde con frecuencia y merece nombrarse: la hora actual. Elm no puede leer el reloj desde una función pura, así que el instante inicial suele entregarse como flag, y a partir de ahí el paso del tiempo se obtiene con suscripciones o con comandos. Confundir los dos mecanismos produce un patrón frágil que se ve a menudo: entregar por flags algo que cambia, guardarlo en el modelo y olvidar que envejece.