En la vista: `NavigationStack` con el store y el `NavigationLink` de TCA

Todo lo que has modelado hasta aquí vive en el estado, y el estado por sí solo no dibuja nada. El puente entre StackState y NavigationStack es el punto donde la tesis de la navegación como datos se pone a prueba de verdad, porque SwiftUI también guarda su propia idea de qué hay en pantalla y las dos versiones tienen que coincidir siempre, en las dos direcciones y sin excepciones. Si el reducer apila, la pantalla debe aparecer; si el usuario arrastra desde el borde, el estado debe encogerse. TCA resuelve esa biyección con una única pieza —un binding derivado del store mediante scope— y a partir de ahí la vista deja de decidir nada sobre navegación: se limita a mostrar lo que la pila dice que hay. Esta lección monta ese lado visual sin sacrificar un gramo de la propiedad que lo hace valioso.

El binding que ata la pila a la vista

La vista raíz declara el store como enlazable y deriva de él, con scope, un binding que el NavigationStack entiende. Esa llamada no copia la pila: produce una vista de escritura sobre el campo camino del estado, de modo que cualquier cambio que SwiftUI intente hacer sobre el camino se traduce en una acción que entra por el canal de siempre.

struct TiendaView: View {
  @Bindable var store: StoreOf<Tienda>

  var body: some View {
    NavigationStack(
      path: $store.scope(state: \.camino, action: \.camino)
    ) {
      List(store.destacados) { producto in
        NavigationLink(state: Tienda.Camino.State.producto(Producto.State(id: producto.id))) {
          Text(producto.nombre)
        }
      }
      .navigationTitle("Destacados")
    } destination: { store in
      switch store.case {
      case let .producto(store): ProductoView(store: store)
      case let .resena(store): ResenaView(store: store)
      case let .perfil(store): PerfilView(store: store)
      }
    }
  }
}

Léelo despacio porque cada pieza justifica su sitio. El primer argumento es el binding a la pila. El bloque principal es la raíz, la pantalla que siempre está debajo de todo y que no vive dentro de StackState. Y el cierre destination recibe, por cada elemento apilado, un store ya reducido al dominio de ese elemento; store.case es la propiedad que la macro @Reducer sintetiza en el enum de rutas para poder hacer switch obteniendo en cada rama un store del tipo exacto de esa feature.

NavigationLink(state:): empujar un estado, no un valor

SwiftUI ofrece de serie un enlace que empuja un valor identificable y delega en un modificador de destino la tarea de traducir ese valor a una vista. TCA aporta una variante que empuja directamente el State del destino, y la diferencia no es cosmética: significa que la pantalla que se abre nace completamente inicializada, con todos sus campos puestos por quien la empuja, en lugar de tener que reconstruirse a partir de un identificador suelto.

NavigationLink(state: Tienda.Camino.State.resena(Resena.State(producto: producto, autor: autor))) {
  Label("Ver reseña", systemImage: "text.bubble")
}

Que el destino nazca completo tiene una consecuencia visible que suele atribuirse al rendimiento y en realidad es de diseño: la pantalla nueva no parpadea. No hay un instante en que exista con los campos vacíos mientras alguien va a buscar el dato, porque el dato ya viajó dentro del estado que la empujó. La carga interna queda reservada para lo que de verdad no se puede saber antes de llegar, y el número de estados de carga que hay que modelar en la aplicación baja de forma notable.

Ese enlace tiene un requisito estricto de contexto: solo funciona dentro de un NavigationStack cuyo camino provenga de un scope sobre un store. Fuera de ese contexto no encuentra la pila a la que dirigirse y TCA emite un aviso en tiempo de ejecución en vez de fallar en silencio. El aviso vale su peso en oro cuando alguien extrae una subvista a un módulo de previsualización y se pregunta por qué el enlace no hace nada.

La tercera fila es la que revela el orden real de las cosas. El enlace declarativo es una comodidad para el caso trivial; la vía canónica y siempre disponible es que el reducer añada a la pila, porque el estado es la fuente de la verdad y la vista solo lo refleja. En cuanto hay una condición que evaluar, la vista deja de ser competente para decidir y se limita a informar de la intención.

Button("Continuar") {
  store.send(.continuarPulsado)
}
.disabled(store.formulario.estaVacio)

Ese botón no sabe adónde lleva ni si llevará a alguna parte: anuncia una pulsación y espera. El reducer, que sí ve el resto del estado, decide si valida, si carga, si apila o si muestra un error. La asimetría es deliberada y es la misma que atraviesa todo TCA desde el Nivel 8: la vista describe lo que ocurrió, nunca lo que debe ocurrir.

Compatibilidad y disciplina del reflejo

Hay un error de montaje que conviene nombrar antes de seguir porque se comete una vez y cuesta media tarde: anidar un NavigationStack dentro de una pantalla de destino. Cada pila que declares crea su propia navegación independiente, de modo que una pila dentro de otra produce dos barras de título, dos botones atrás y un estado que ya no describe lo que hay en pantalla. Las vistas de destino son contenido, no contenedores; el único NavigationStack del flujo vive en la raíz y todas las demás pantallas se limitan a poblarlo. La regla se recuerda fácil: si una vista aparece en el cierre destination, no puede declarar una pila.

En objetivos anteriores a la observación nativa de SwiftUI, la biblioteca de compatibilidad que viste en el Nivel 6 cubre exactamente el mismo código con dos cambios mecánicos: el store enlazable se declara con la variante de la biblioteca de percepción y el cuerpo se envuelve en el contenedor que activa el seguimiento.

struct TiendaView: View {
  @Perception.Bindable var store: StoreOf<Tienda>

  var body: some View {
    WithPerceptionTracking {
      NavigationStack(path: $store.scope(state: \.camino, action: \.camino)) {
        // raíz
      } destination: { store in
        WithPerceptionTracking {
          switch store.case { /* ... */ }
        }
      }
    }
  }
}

Salvo esos dos envoltorios, la estructura es idéntica y la disciplina también: la vista nunca decide navegación, solo la dibuja. Ese es el criterio con el que revisar cualquier pantalla de un flujo apilado, y el más fácil de aplicar en una revisión de código, porque se comprueba de un vistazo. Si en el cuerpo de una vista encuentras una variable de estado local que recuerda si algo está presentado, una bandera que decide qué mostrar o un gesto que descarta por su cuenta, esa vista dejó de ser un reflejo y volvió a ser un depósito, y con ella regresa la posibilidad de que su idea de la navegación difiera de la del reducer.

flowchart LR
ST[StackState en el estado] -->|scope produce binding| NS[NavigationStack]
NS -->|cierre destination| D[Store reducido por elemento]
NL[NavigationLink con state] -->|push| ST
GB[Gesto atras del sistema] -->|popFrom| ST
style ST fill:#89b4fa,color:#11111b
style GB fill:#a6e3a1,color:#11111b