En la vista: `sheet`, `fullScreenCover` y `popover` con `$store.scope`

En SwiftUI corriente, presentar una hoja es cosa de un booleano que la vista posee y voltea. Ese diseño tiene un defecto que solo se nota cuando la app crece: la verdad de qué hay en pantalla vive en la capa de vistas, dispersa entre banderas locales, y no hay forma de preguntarle al modelo dónde está el usuario. TCA invierte el sentido de la flecha. El modelo ya sabe qué hay presentado, porque presentar fue asignar un valor a un hueco, y lo que la vista necesita no es decidir sino enterarse. La pieza que la entera es una familia de sobrecargas de los modificadores de siempre que, en lugar de un Bool o un identificable suelto, aceptan un binding a un store opcional: si el store existe, hay pantalla y ahí está su feature completa; si no existe, no hay nada que presentar. Toda la lección cabe en esa sustitución, pero sus consecuencias llegan hasta el testing.

Del hueco del estado al binding de SwiftUI

La vista declara su store como @Bindable y deriva de él un binding a un store hijo opcional. Ese binding es lo único que el modificador necesita.

struct InventarioView: View {
  @Bindable var store: StoreOf<Inventario>

  var body: some View {
    List {
      ForEach(store.articulos) { articulo in
        Button(articulo.nombre) { store.send(.articuloPulsado(articulo.id)) }
      }
    }
    .sheet(item: $store.scope(state: \.detalle, action: \.detalle)) { detalleStore in
      DetalleView(store: detalleStore)
    }
  }
}

Tres detalles merecen atención en esas dos líneas. El primero es el item: en lugar de isPresented:: la sobrecarga que usamos no recibe un booleano sino un valor opcional identificable, y aquí ese valor es el propio store del hijo, que TCA hace conformar a Identifiable usando el identificador de presentación de la lección anterior. Presentar y descartar dejan de ser dos estados de una bandera y pasan a ser la presencia o ausencia de un objeto con identidad, que es justo lo que SwiftUI necesita para animar el reemplazo de un detalle por otro sin cerrar y reabrir la hoja.

El segundo es el key path sin dólar. En el reducer escribías \.$detalle porque ifLet necesita el envoltorio completo; aquí escribes \.detalle porque la vista solo quiere el valor, y @ObservableState se encarga de que leerlo registre la dependencia de observación. El tercero es el más importante y el menos visible: DetalleView recibe un StoreOf<Detalle> y nada más. Ni una closure de cierre, ni un binding al booleano del padre, ni una referencia al padre. La feature presentada ignora por completo que está dentro de una hoja.

Cuatro modificadores, un mismo patrón

La familia entera sigue la misma forma, así que elegir es una decisión de diseño de interfaz y no de arquitectura.

.fullScreenCover(item: $store.scope(state: \.bienvenida, action: \.bienvenida)) { bienvenidaStore in
  BienvenidaView(store: bienvenidaStore)
}
.popover(item: $store.scope(state: \.filtros, action: \.filtros)) { filtrosStore in
  FiltrosView(store: filtrosStore)
}
.navigationDestination(item: $store.scope(state: \.perfil, action: \.perfil)) { perfilStore in
  PerfilView(store: perfilStore)
}

Cuando el hueco es un enum de destino, el scope gana una interrogación en el lado del estado y una ruta de caso en el lado de la acción, y se escribe un modificador por cada caso que quieras presentar de una forma distinta.

.sheet(item: $store.scope(state: \.destino?.editar, action: \.destino.editar)) { editorStore in
  EditorView(store: editorStore)
}
.popover(item: $store.scope(state: \.destino?.ajustes, action: \.destino.ajustes)) { ajustesStore in
  AjustesView(store: ajustesStore)
}

La lectura del par es directa: del estado, dame el hueco si está lleno y además si su caso es editar; de las acciones, envuelve lo que salga de ahí en destino y luego en editar. Como el hueco es uno solo, jamás habrá dos de esos modificadores con store no nulo a la vez, y por eso conviven en la misma vista sin pelearse por quién presenta.

Quién descarta cuando el usuario arrastra

Aquí está el detalle que separa esta integración de un truco de conveniencia. El binding que produce $store.scope no es de solo lectura: SwiftUI escribe en él cuando el usuario cierra la hoja con un gesto, pulsa fuera del popover o toca el botón atrás. Y lo que ese binding hace al recibir nil no es mutar el estado —la vista no tiene permiso para mutar nada— sino enviar al store la acción .destino(.dismiss), que viaja por el mismo camino unidireccional que cualquier otra.

flowchart TD
ST[State con hueco presentado] --> SC[dollar store scope produce store opcional]
SC --> MOD[Modificador sheet o popover]
MOD --> V[Vista del hijo con su store]
V -->|acciones del hijo| ST
G[Gesto de descarte del usuario] --> B[El binding escribe nil]
B -->|envia PresentationAction dismiss| RED[Reducer del padre e ifLet]
RED --> ST
style ST fill:#89b4fa,color:#11111b
style B fill:#f9e2af,color:#11111b

La consecuencia práctica es enorme y conviene enunciarla sin rodeos: no existe ninguna forma de que una pantalla desaparezca sin que una acción lo cuente. El gesto más informal del sistema operativo —arrastrar una hoja hacia abajo— entra por la misma puerta que un toque en un botón, queda registrado en _printChanges, se puede afirmar en un TestStore y puede desencadenar efectos como cualquier otra acción. Esa propiedad es lo que hace que las cuatro cosas siguientes salgan gratis.

La segunda de esas propiedades se comprueba en diez segundos y es la mejor prueba de que la integración está bien hecha: una preview que arranca con el hueco ya lleno debe mostrar la hoja abierta desde el primer fotograma, sin animación de apertura y sin que nadie envíe ninguna acción.

#Preview("Arrancando con el editor abierto") {
  InventarioView(
    store: Store(
      initialState: Inventario.State(
        articulos: [.prueba],
        destino: .editar(Editor.State(borrador: .prueba))
      )
    ) {
      Inventario()
    }
  )
}

Si esa preview funciona, tu deep linking ya funciona, porque abrir la app desde una URL profunda es exactamente lo mismo con otro punto de entrada. Y si no funciona, el fallo casi siempre está en el mismo sitio: una vista que sigue guardando estado de presentación propio y necesita un evento para sincronizarse con el modelo.

Una última nota de oficio sobre la vista del hijo. Cuando la feature presentada necesita barra de navegación, botones de cabecera o su propio título, el NavigationStack va dentro de la closure del modificador y envuelve a la vista hija, no al revés: la pila pertenece a la presentación, no a la feature, y meterla dentro del hijo le impediría servir también empujada en la pila de su padre.