`StackState` y `StackAction`: la pila de pantallas como colección

En el Nivel 15 aprendiste que una lista de features no exige una lista de reducers: basta un reducer multiplicado por forEach sobre una colección identificada. La navegación en pila es exactamente ese mismo teorema aplicado a una dimensión distinta. Una pila de pantallas no es más que una colección ordenada de estados, donde el orden significa profundidad en vez de posición visual, y donde los elementos, a diferencia de las filas de una tabla, no son todos del mismo tipo: la primera puede ser un detalle de producto, la segunda una reseña, la tercera el perfil de quien la escribió. StackState es la estructura que sostiene esa colección heterogénea, y StackAction el sobre con el que se le habla. Juntos consiguen algo que sorprende la primera vez que se ve: cinco pantallas encadenadas producen dos envoltorios de acción, no cinco.

La pila como colección de estados heterogéneos

Una pila necesita poder contener pantallas de tipos distintos, y en un lenguaje de tipos estáticos eso solo se resuelve de una manera honesta: con una suma. Por eso StackState no se declara sobre una feature concreta sino sobre el State de un @Reducer enum que enumera los destinos alcanzables.

@Reducer
struct Tienda {
  @Reducer
  enum Camino {
    case producto(Producto)
    case resena(Resena)
    case perfil(Perfil)
  }

  @ObservableState
  struct State: Equatable {
    var destacados: [Producto.Modelo] = []
    var camino = StackState<Camino.State>()
  }

  enum Action {
    case camino(StackActionOf<Camino>)
  }
}

StackState<Camino.State> es una colección de acceso aleatorio, mutable y reemplazable por rangos: puedes recorrerla, contarla, indexarla y modificarla como cualquier array. Lo que la distingue es que cada elemento, al entrar, recibe una identidad generada por la propia estructura, y esa identidad —no la posición— es la que gobierna el enrutado. StackActionOf<Camino> es la abreviatura de StackAction<Camino.State, Camino.Action>, la misma economía notacional que ya viste en IdentifiedActionOf.

Los tres casos de StackAction

El sobre con el que se conversa con una pila tiene exactamente tres formas, y conviene aprender de memoria quién emite cada una porque de ahí sale la mitad del razonamiento sobre navegación.

El caso element es el gemelo del que ya conoces de las colecciones identificadas: lleva remitente y mensaje, y el remitente es la identidad de la pantalla, no su profundidad. El caso popFrom es el más interesante de los tres porque llega sin que nadie de tu código lo haya pedido: cuando el usuario pulsa el botón atrás o arrastra desde el borde, SwiftUI retira la pantalla y TCA traduce ese hecho a una acción que tu reducer puede observar. El retroceso deja de ser un suceso invisible del sistema de vistas para convertirse en un dato con nombre que atraviesa el mismo canal que todo lo demás.

var body: some ReducerOf<Self> {
  Reduce { state, action in
    switch action {
    case let .camino(.popFrom(id: id)):
      print("El usuario abandonó", state.camino[id: id] as Any)
      return .none
    case .camino:
      return .none
    }
  }
  .forEach(\.camino, action: \.camino)
}

Fíjate en un detalle de secuencia que importa: cuando llega popFrom, el elemento todavía está en la pila, de modo que puedes leerlo por su id antes de que desaparezca. Es la última oportunidad de inspeccionar lo que el usuario deja atrás, y de ahí sale un patrón que aparecerá una y otra vez: guardar un borrador abandonado, registrar cuánto tiempo duró la visita, o preguntar si de verdad quiere salir sin guardar.

El caso push merece una nota aparte porque su origen desconcierta al principio. No lo emite tu reducer: cuando el usuario activa un enlace de navegación, es la vista quien anuncia que ha apilado algo, y tu reducer se entera del hecho consumado igual que se entera del retroceso. Cuando eres tú quien decide apilar —porque una respuesta de red llegó, porque una validación pasó—, no envías esa acción: mutas la colección directamente. Ambas vías conducen al mismo sitio, y esa simetría es la que hace que la pila no tenga nunca dos versiones de sí misma.

Identidad opaca: por qué no se indexa por posición

Cada elemento que entra en StackState recibe un StackElementID producido por la dependencia stackElementID. Es un valor opaco, monótonamente creciente y jamás reutilizado dentro de la vida del proceso: si desapilas la pantalla número tres y empujas otra, la nueva no hereda el identificador de la anterior.

// Enrutado por identidad, no por profundidad
state.camino[id: id]?.modifica()

// Y la colección sigue siendo una colección
state.camino.count
state.camino.last
state.camino.ids

Las tres formas conviven sin estorbarse porque describen cosas distintas. La cuenta y el último elemento sirven para preguntar por la forma de la pila; los identificadores sirven para dirigirse a una pantalla concreta; y el subíndice por identidad es la única vía correcta de mutar un elemento, porque no depende de dónde esté.

El motivo de esa irrepetibilidad es una clase entera de fallo que desaparece. Imagina que la tercera pantalla lanzó una petición de red y el usuario retrocede antes de que responda; luego empuja otra pantalla distinta, que ocupa la misma posición tres. Si el enrutado fuese posicional, la respuesta tardía aterrizaría en una pantalla que no la pidió y mutaría datos ajenos. Con identidad opaca, esa acción tardía se dirige a un id que ya no existe: no muta nada y emite un aviso en tiempo de ejecución. Es el mismo razonamiento que sostenía IdentifiedArrayOf en el Nivel 15, ascendido a la dimensión de la profundidad.

flowchart TD
V[Enlace de navegacion en la vista] --> P[StackAction push con id nuevo]
P --> S[StackState guarda el estado del destino]
S --> F[forEach corre el reducer de ese elemento]
U[Gesto atras del usuario] --> Q[StackAction popFrom con id]
Q --> R[El padre puede leer el elemento]
R --> X[forEach cancela los efectos de ese id]
style S fill:#89b4fa,color:#11111b
style X fill:#a6e3a1,color:#11111b

Esa identidad no la inventa la estructura por su cuenta: la produce la dependencia stackElementID, que es una dependencia como cualquier otra de las del Nivel 12 y por tanto controlable. En producción entrega valores opacos e imprevisibles; bajo un TestStore entrega enteros que empiezan en cero y avanzan de uno en uno, de modo que una prueba de navegación puede nombrar sus pantallas con números pequeños y legibles en vez de con identificadores generados al azar. Es el mismo truco que hizo determinista al reloj y al generador de identificadores únicos, aplicado ahora a la profundidad.

El operador que cierra el montaje es forEach, el mismo nombre del Nivel 15 pero con una sobrecarga específica para pilas. Aplicado sobre un @Reducer enum no lleva closure final, porque la macro ya sintetizó el reducer que despacha cada caso a su feature. Y su efecto es el que ya conoces multiplicado por la profundidad: corre el reducer del destino que la identidad señale, fuerza el orden hijo antes que padre, y cancela todos los efectos en vuelo de una pantalla en el instante en que se desapila. El temporizador de la pantalla cuatro se apaga solo cuando el usuario retrocede a la tres.

Ese orden forzado tiene aquí la misma justificación que en las colecciones y conviene tenerla presente desde el principio. Cuando llega una acción dirigida a un elemento, el reducer de esa pantalla la procesa antes que el reducer raíz, de modo que la raíz puede desapilarla con seguridad al atender la misma acción: la pantalla ya reaccionó a su propio mensaje, ya canceló lo que tuviera que cancelar, y solo entonces desaparece. Si el orden fuese el inverso, cualquier reacción de la raíz que truncase la pila dejaría mensajes sin entregar en pantallas que se esfumaron a mitad de camino.