Navegación programática: pushUrl, replaceUrl y la disciplina del historial

El botón de retroceso es probablemente el control más usado de toda la informática de consumo y, con casi total seguridad, el menos considerado en las decisiones de diseño de las aplicaciones que lo pueblan. Nadie escribe una especificación para él, nadie lo prueba de forma sistemática y sin embargo cualquier usuario detecta en tres segundos que una aplicación lo ha estropeado: pulsa atrás esperando volver a la lista y vuelve al formulario que acaba de enviar, o pulsa atrás quince veces porque cada tecla que escribió en un buscador dejó una entrada, o pulsa atrás y reaparece la pantalla de inicio de sesión que ya superó. Ninguno de esos defectos es un fallo de programación en el sentido habitual: son consecuencias directas de haber elegido mal entre dos comandos que se parecen tanto que invitan a no pensar. pushUrl añade una entrada al historial y replaceUrl sustituye la actual, y esa es toda la diferencia. Esta lección trata de por qué esa diferencia mínima es una de las decisiones de diseño con más impacto perceptible por unidad de código de toda la aplicación, y de cómo elegir sin dudar en cada caso concreto.

Navegar es emitir un comando, no asignar un campo

La navegación programática entra en la arquitectura por donde entra todo lo demás: update devuelve un comando y el runtime lo ejecuta. Los dos comandos que interesan reciben la clave de navegación y una dirección en forma de texto, y su efecto es alterar el historial del navegador. Nada más. En particular, no tocan el modelo, y esa es la parte que conviene fijar bien: emitir Nav.pushUrl no cambia la ruta guardada. Lo que ocurre es que el historial cambia, el runtime detecta el cambio, construye el mensaje que declaraste en onUrlChange y lo entrega a update, que entonces sí actualiza el estado. El ciclo pasa por fuera y vuelve a entrar, exactamente igual que el de un clic en un enlace.

Nav.pushUrl : Nav.Key -> String -> Cmd msg
Nav.replaceUrl : Nav.Key -> String -> Cmd msg


update msg model =
    case msg of
        ArticuloGuardado (Ok articulo) ->
            ( model
            , Nav.pushUrl model.key (Route.toString (Route.Articulo articulo.id))
            )

        BusquedaEscrita texto ->
            ( { model | page = Buscador texto }
            , Nav.replaceUrl model.key (Route.toString (Route.Buscar texto))
            )

De que el ciclo pase por fuera se sigue una consecuencia práctica que ahorra depuraciones desconcertantes: si emites el comando y además actualizas la ruta del modelo en la misma rama, estás escribiendo el estado dos veces, una a mano y otra cuando llegue el mensaje de cambio, y la primera es siempre la que puede equivocarse. Deja que el modelo lo actualice únicamente el manejador de cambio de dirección y trata los dos comandos como lo que son: una petición al navegador para que modifique su historial, cuyo eco volverá por el camino normal.

Que la firma exija una Nav.Key no es un capricho de la biblioteca. Esa clave es un valor opaco que solo se obtiene como argumento de init en un Browser.application, no se puede construir, no se puede falsificar y no se puede leer de ningún sitio global. La consecuencia es estructural: ninguna función de un programa que no se haya declarado responsable de la navegación puede alterar el historial, y en un programa que sí lo es, la clave tiene que haberse guardado explícitamente en el modelo y pasarse hasta el punto donde se usa. Es la misma idea de capacidad que gobierna los cuatro constructores, llevada al nivel de una función concreta.

El historial es una pila que el usuario también manipula

La elección entre los dos comandos se vuelve fácil en cuanto se enuncia el criterio correcto, que no habla de código sino de percepción: cada entrada del historial debe corresponder a un paso que el usuario reconocería como propio, es decir, a un sitio al que le parecería razonable volver pulsando atrás una sola vez. Si el estado nuevo es un destino al que el usuario ha llegado deliberadamente, se empuja. Si el estado nuevo sustituye a uno que ya no debería existir —porque era un tránsito, una redirección o una versión anterior del mismo sitio—, se reemplaza.

El resto del módulo de navegación completa el cuadro con cuatro funciones que conviene tener presentes aunque se usen poco. Nav.back y Nav.forward mueven el cursor por la pila sin añadir entradas, y sirven para ofrecer un control de volver propio dentro de la interfaz; hay que recordar que la pila puede no tener nada detrás cuando el usuario llegó por un enlace directo, así que un botón que solo retrocede deja al recién llegado sin salida y suele ser preferible navegar a un destino conocido. Nav.load y Nav.reload abandonan la aplicación de verdad: destruyen el documento, pierden el estado en memoria y arrancan de cero. Esa pérdida total es indeseable casi siempre y exactamente lo que se quiere al cerrar sesión, porque garantiza que no queda ni un rastro del usuario anterior en ninguna parte del programa.

Nav.back : Nav.Key -> Int -> Cmd msg
Nav.forward : Nav.Key -> Int -> Cmd msg
Nav.load : String -> Cmd msg
Nav.reload : Cmd msg


update msg model =
    case msg of
        CerrarSesion ->
            -- No basta con vaciar el modelo: se recarga para no dejar rastro
            ( model, Nav.load (Route.toString Route.Inicio) )

        VolverAtras ->
            ( model, Nav.back model.key 1 )

Los dos casos que más se estropean en la práctica son la redirección y el formulario. Tras iniciar sesión, empujar la pantalla de destino deja el formulario de acceso justo detrás, de modo que un retroceso devuelve al usuario autenticado a una pantalla que ya no tiene sentido para él; hay que reemplazar. Tras guardar un formulario, empujar la ficha creada está bien, pero solo si el formulario mismo no se rellenó en varios pasos intermedios que empujaron sus propias entradas: en ese caso, atrás recorre el formulario hacia atrás paso a paso y el usuario acaba mirando un borrador que ya envió. Y en un buscador que actualiza la dirección con cada pulsación, empujar convierte el botón de retroceso en una máquina de borrar letras de una en una, que es el ejemplo canónico de trampa de historial.

flowchart TD
A[Accion del usuario] --> D[Es un destino nuevo]
D --> P[Si pushUrl anade entrada]
D --> R[No replaceUrl sustituye entrada]
P --> H[Historial]
R --> H
B[Boton atras] --> H
H --> O[onUrlChange]
O --> M[Model actualizado]
style P fill:#89b4fa,color:#11111b
style R fill:#f9e2af,color:#11111b
style M fill:#a6e3a1,color:#11111b

Pulsar atrás como método de auditoría

Hay una prueba muy barata y sorprendentemente reveladora que conviene convertir en costumbre antes de cada entrega: recorrer los flujos principales de la aplicación y después pulsar el botón de retroceso repetidamente hasta salir, anotando qué aparece en cada paso. La prueba no requiere herramientas y detecta de inmediato las cuatro patologías clásicas. La primera es la entrada fantasma, un estado en el historial que el usuario nunca percibió como un sitio y al que volver resulta desconcertante. La segunda es la trampa, un par de estados que se redirigen mutuamente y del que no se sale hacia atrás. La tercera es la pérdida, una pantalla que al volver a ella aparece vacía porque su estado no estaba en la dirección. La cuarta es la inundación, decenas de entradas generadas por interacciones continuas.

Hay un patrón que conviene tener resuelto de antemano porque aparece en toda aplicación con sesión: la ruta protegida. Al entrar en una pantalla que exige autenticación sin estarlo, la aplicación debe redirigir al acceso recordando el destino, y volver a él una vez autenticado. Las dos navegaciones de ese flujo son de reemplazo, no de empuje, porque ni la pantalla protegida a la que no se pudo entrar ni el formulario de acceso ya superado son sitios a los que tenga sentido volver.

entrar : Route -> Model -> ( Model, Cmd Msg )
entrar ruta model =
    case ( ruta, model.sesion ) of
        ( Route.Panel, Anonimo ) ->
            ( model
            , Nav.replaceUrl model.key (Route.toString (Route.Acceso ruta))
            )

        ( Route.Panel, Autenticado usuario ) ->
            ( { model | page = Panel usuario }, Cmd.none )

        _ ->
            ( model, Cmd.none )

Queda un caso incómodo que merece mención honesta: el usuario que abandona una pantalla con cambios sin guardar. La intercepción del clic permite avisarlo, porque el mensaje llega antes de que nada ocurra y la actualización puede decidir no empujar la dirección y mostrar una confirmación. El botón de retroceso, en cambio, no da esa oportunidad, porque cuando el programa se entera el cambio ya está consumado. Se puede reaccionar volviendo a empujar la dirección anterior, pero es un remiendo perceptible y conviene reconocerlo como tal. La lección de fondo es que la protección real no viene de interceptar la salida sino de reducir la cantidad de estado valioso que solo existe en memoria.