La tesis: la navegación es un valor del estado

Toda arquitectura de interfaz responde, quiera o no, a una pregunta ontológica muy simple: ¿qué clase de cosa es estar en una pantalla? El modelo imperativo responde que es el residuo de una acción pasada, el efecto acumulado de una secuencia de órdenes que alguien dio en algún momento y de la que ya solo queda el rastro dentro del sistema de vistas. TCA responde otra cosa, y esa respuesta es el eje del nivel entero: estar en una pantalla es un hecho presente, un valor que el estado sostiene ahora mismo, tan dato como el nombre de un usuario o el contador de un carrito. La diferencia parece de estilo y es de naturaleza. Un residuo no se puede leer, ni comparar, ni guardar en disco, ni reconstruir a voluntad; un valor sí. Todo lo que este nivel promete —deep linking sin ceremonia, restauración de sesión, tests de flujos completos, desaparición de estados imposibles— es consecuencia mecánica de haber cambiado la respuesta a esa pregunta.

La pregunta que una app imperativa no sabe responder

Detén cualquier app tradicional en el depurador y pregúntale qué tiene encima. No hay ningún sitio donde mirar. La respuesta está repartida entre la pila del controlador de navegación, un puñado de booleanos que gobiernan hojas, el estado interno de las animaciones en curso y, si hay suerte, alguna variable que alguien recordó actualizar. La única forma de saberlo con certeza es preguntarle al sistema de vistas, es decir, a la capa que debería ser el reflejo de la verdad y no su depositaria.

// La verdad vive fuera del modelo: solo queda el rastro de la orden
func filaTocada(_ item: Item) {
  let detalle = DetalleVC(item: item)
  navigationController?.pushViewController(detalle, animated: true)
}

// La versión SwiftUI cambia la sintaxis, no la ontología
@State private var mostrarDetalle = false
@State private var itemSeleccionado: Item?

Ese par de propiedades independientes es el síntoma exacto del problema. Nada impide que mostrarDetalle sea verdadero mientras itemSeleccionado es nulo, ni al revés, porque son dos hechos que el compilador considera ajenos entre sí aunque en el dominio sean uno solo. La orden imperativa no solo dispersa la verdad: la fragmenta en trozos que pueden contradecirse. Y como el sistema de vistas es quien realmente sabe qué hay en pantalla, cualquier intento de sincronizar el modelo con él es una carrera que se pierde tarde o temprano, cuando el usuario desliza para volver atrás y nadie avisa a las banderas.

Presentar es asignar, descartar es borrar

La propuesta de TCA cabe en una frase: el destino es un campo más del estado. El anotador @Presents marca ese campo como un hueco de presentación, PresentationAction unifica en un solo caso de acción los mensajes que vienen de dentro del hijo y el hecho de que el hijo se descartó, y ifLet ata el ciclo de vida del reducer hijo a la existencia de ese valor.

@Reducer
struct Lista {
  @ObservableState
  struct State: Equatable {
    var items: IdentifiedArrayOf<Item> = []
    @Presents var detalle: Detalle.State?
  }

  enum Action {
    case filaTocada(Item.ID)
    case detalle(PresentationAction<Detalle.Action>)
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .filaTocada(id):
        guard let item = state.items[id: id] else { return .none }
        state.detalle = Detalle.State(item: item)   // presentar
        return .none
      case .detalle(.dismiss):
        return .none                                 // el nil ya lo puso TCA
      case .detalle:
        return .none
      }
    }
    .ifLet(\.$detalle, action: \.detalle) { Detalle() }
  }
}

No hay ninguna llamada a navegación en ese reducer, y esa ausencia es el punto entero. Presentar el detalle es escribir un valor; descartarlo es escribir nulo. La vista se limita a observar el hueco y a materializarlo con el modificador que corresponda, de modo que la dirección de la causalidad queda fijada: del estado a la pantalla, nunca al revés.

struct ListaView: View {
  @Bindable var store: StoreOf<Lista>

  var body: some View {
    List(store.items) { item in
      Button(item.titulo) { store.send(.filaTocada(item.id)) }
    }
    .sheet(item: $store.scope(state: \.detalle, action: \.detalle)) { store in
      DetalleView(store: store)
    }
  }
}

El scope sobre el binding es la costura que cierra el círculo: cuando el usuario descarta la hoja con un gesto, SwiftUI escribe nulo a través de ese binding, eso se traduce en la acción dismiss, y el reducer del padre se entera del descarte como se entera de cualquier otro hecho del mundo. No hay ningún camino por el que la pantalla pueda cambiar sin que el estado lo sepa.

La interfaz como función del estado

Detrás de todo esto hay una tesis más general, heredada de Elm y anterior a TCA: la vista es una función pura del estado. Escrito como ecuación, vista igual a f de estado. Si esa igualdad se cumple de verdad, entonces todo lo que se ve en pantalla —incluida la pantalla misma— tiene que ser deducible del estado, porque una función no puede devolver algo que no esté determinado por su entrada. La navegación imperativa rompe la ecuación por la mitad: introduce una variable oculta, la pila real del sistema, que influye en el resultado sin aparecer en la entrada. Modelar la navegación como dato no es un truco de conveniencia; es lo mínimo necesario para que la ecuación vuelva a ser cierta.

flowchart LR
S[State con el destino] --> V[Vista refleja el destino]
V -->|intencion del usuario| A[Action]
A --> R[Reducer asigna o borra el destino]
R --> S
O[Orden imperativa] -.-> P[Pila real del sistema]
P -.-> Q[Verdad dispersa fuera del modelo]
style S fill:#89b4fa,color:#11111b
style Q fill:#f38ba8,color:#11111b