Navegación hacia atrás: volver sin perder nada

El botón de volver es la funcionalidad más barata de prometer y la más cara de cumplir. Prometerla cuesta una flecha en el diagrama; cumplirla obliga a responder a qué se vuelve exactamente, porque un paso no es un punto sino un conjunto de cosas que ocurrían a la vez: lo que el usuario había escrito, dónde tenía el foco, qué subpantalla del paso estaba abierta, qué validaciones ya habían pasado. La implementación descuidada devuelve al usuario al nombre del paso y nada más, y el efecto es demoledor porque parece un castigo: quien retrocede para corregir una letra encuentra el formulario en blanco y aprende, muy rápido, a no volver nunca. Las dos pérdidas tienen causas técnicas distintas y remedios distintos, y separarlas es la mitad del trabajo.

Dos pérdidas con causas distintas

La primera pérdida, la de los datos, casi nunca es culpa de la máquina. El contexto pertenece al actor entero y no a ningún estado, así que una transición entre pasos hermanos no lo toca: lo que se guardó al avanzar sigue ahí al volver. Si el formulario aparece vacío, el culpable es otro y suele ser el mismo siempre: el paso guardaba lo que el usuario escribía en el estado local de su componente, y ese componente se desmontó al cambiar de pantalla. El remedio no es un truco de persistencia, es reconocer que el asistente tiene un dueño de los datos y que ese dueño es el actor, no la vista.

export function crearBorradorDireccion(actor: ActorRefFrom<typeof alta>) {
  const guardado = actor.getSnapshot().context.datos
  const borrador = {
    calle: guardado.calle ?? '',
    ciudad: guardado.ciudad ?? '',
  }
  return {
    borrador,
    escribir: (campo: 'calle' | 'ciudad', valor: string) => {
      borrador[campo] = valor
    },
    continuar: () => actor.send({ type: 'SIGUIENTE', parche: borrador }),
  }
}

El borrador local sigue existiendo, y está bien que exista: teclear no tiene por qué producir una transición. Lo que cambia es su origen y su destino. Se inicializa desde el contexto, de modo que volver lo repuebla, y se entrega al contexto al avanzar, de modo que salir no lo pierde. El componente pasa a ser una vista temporal sobre un dato que vive en otro sitio, que es justo lo que debía ser.

La segunda pérdida sí es responsabilidad del modelo y es estructural. Salir de un estado compuesto destruye su configuración interior: la máquina abandona la hoja, luego el padre, y al reentrar arranca por el subestado inicial. Mientras cada paso sea una pantalla plana eso da igual, porque no hay interior que perder. En cuanto un paso tiene subpasos —el pago que primero elige método y después pide los datos de la tarjeta, la dirección que ofrece buscar por código postal o rellenar a mano— volver a ese paso significa volver a su principio, y el usuario que solo quería revisar un dígito se encuentra otra vez eligiendo método de pago.

Historia para lo que el paso tenía dentro

El pseudoestado de historia cancela ese olvido. Declarado como hijo del compuesto, no es un lugar donde la máquina repose sino una instrucción de reentrada que se resuelve en el mismo microstep: consulta qué configuración había grabada al salir y entra directamente allí.

pago: {
  initial: 'metodo',
  states: {
    metodo: { on: { ELEGIR: 'tarjeta' } },
    tarjeta: {
      initial: 'numero',
      states: {
        numero: { on: { CONTINUAR: 'titular' } },
        titular: { on: { ATRAS: 'numero' } },
      },
      on: { CAMBIAR_METODO: 'metodo' },
    },
    hist: { type: 'history', history: 'deep', target: 'metodo' },
  },
  on: { SIGUIENTE: 'revision', ATRAS: 'direccion' },
},
revision: {
  on: { ATRAS: 'pago.hist', CONFIRMAR: 'enviando' },
},

La diferencia entre las dos profundidades se decide por una única pregunta: cuántos niveles quiero restaurar. La superficial devuelve al hijo directo que estaba activo y deja que ese hijo arranque por su propio inicial; la profunda restaura el camino entero hasta la hoja. Para un paso con un solo nivel interior son equivalentes; para un subasistente como el del ejemplo, la superficial devolvería al usuario al bloque de la tarjeta pero al primer campo, y la profunda lo devuelve exactamente donde estaba. El target del nodo cubre la primera reentrada, cuando aún no hay nada grabado, y omitirlo es la causa habitual del error al volver por primera vez a un paso que se saltó.

stateDiagram-v2
state pago {
  [*] --> metodo
  metodo --> tarjeta: ELEGIR
  state tarjeta {
    [*] --> numero
    numero --> titular: CONTINUAR
    titular --> numero: ATRAS
  }
  tarjeta --> metodo: CAMBIAR_METODO
}
pago --> revision: SIGUIENTE
revision --> pago: ATRAS via historia profunda

La arista declarada y la pila grabada

Hay dos filosofías para responder a qué significa atrás, y la mayoría de los asistentes rotos mezclan ambas sin darse cuenta. La arista declarada afirma cuál es el paso anterior en sentido lógico: lo escribe el modelador, aparece en el diagrama y es estable. La pila grabada guarda el recorrido real del usuario en el contexto y retrocede por él, sea cual sea el camino que tomó.

El conflicto es real y no tiene ganador universal. Con un flujo lineal la arista declarada es superior en todo: se ve en el dibujo, no añade estado y no puede desincronizarse. En cuanto hay ramas, la arista obliga a repetir en el retroceso la misma condición que gobernó el avance, y esa duplicación es donde aparecen los fallos de asistentes ramificados: se cambia la condición de ida y nadie ajusta la de vuelta. La pila no puede equivocarse sobre el pasado, pero introduce un problema propio y más sutil: si el usuario retrocede varios pasos, cambia una respuesta que altera la rama y vuelve a avanzar, la pila conserva pasos que ya no pertenecen al recorrido válido. Quien elige la pila debe podarla al modificar cualquier respuesta que gobierne una bifurcación, y quien elige aristas debe extraer la condición a una guarda con nombre que usen las dos direcciones.

Falta un tercer actor que nadie invitó y que siempre aparece: el botón de retroceso del navegador. Si cada paso tiene su propia entrada en el historial del navegador, el usuario dispone de dos mecanismos de vuelta con memorias distintas, y en cuanto discrepan el asistente se comporta de forma impredecible. La única arquitectura estable es la que decide quién manda: la máquina es la fuente de verdad, la barra de direcciones es una proyección suya que se actualiza al entrar en cada paso, y el evento de retroceso del navegador no navega a ningún sitio sino que se traduce a un ATRAS ordinario que la máquina resolverá según sus propias reglas.

Volver no es deshacer

La confusión más peligrosa del patrón es tratar el retroceso como una operación de deshacer. Navegar hacia atrás mueve la posición y conserva los datos; deshacer revierte efectos. Mientras el asistente solo recoja información, ambas coinciden y nadie nota la diferencia. En cuanto un paso produce algo fuera —una reserva temporal, un cobro autorizado, un documento firmado, un correo enviado— dejan de coincidir por completo, y una flecha de retroceso dibujada sin pensarlo promete algo que el sistema no puede cumplir.

La consecuencia de diseño es que los pasos con efectos irreversibles no llevan arista de vuelta. Una vez cruzado el punto de no retorno, la salida no es volver sino cancelar, y cancelar es una transición distinta con su propia acción compensatoria: liberar la reserva, anular la autorización, registrar la renuncia. Ese es el motivo por el que el envío merece una lección propia y por el que la pantalla de revisión es el último lugar del flujo desde el que retroceder sigue siendo gratis.