Navegación en árbol y navegación en pila

La lección anterior dejó establecido que la navegación es un valor. Ahora hay que decidir de qué tipo es ese valor, y la respuesta no es indiferente: determina qué trayectos son expresables, qué tan hondo puede llegar el usuario, cuántos envoltorios atraviesa una acción y hasta qué punto el compilador puede ayudarte. Hay dos formas canónicas y conviene entenderlas como lo que son, dos maneras distintas de acotar el infinito. El árbol acota por anticipado: cada pantalla enumera sus destinos posibles en un enum y la profundidad total queda fijada en el momento en que escribes los tipos. La pila renuncia a esa acotación y la sustituye por otra: no sabe cuántas pantallas habrá, pero sí que todas serán del mismo tipo suma y que estarán en fila. Una es un tipo recursivo con fondo; la otra, una secuencia homogénea sin fondo. Elegir mal no rompe nada de inmediato, y por eso el error tarda tanto en manifestarse.

El árbol: destinos declarados, profundidad fijada

En la navegación en árbol cada feature declara el conjunto cerrado de cosas que puede presentar. Ese conjunto se escribe como un @Reducer enum, que la macro convierte a la vez en la suma de los estados posibles y en el reducer que despacha cada caso a su feature. El estado guarda un único hueco opcional de ese tipo, lo que hace aritméticamente imposible tener dos destinos a la vez.

@Reducer
struct Inventario {
  @Reducer
  enum Destino {
    case detalle(DetalleItem)
    case anadir(FormularioItem)
  }
  @ObservableState
  struct State: Equatable {
    var items: IdentifiedArrayOf<Item> = []
    @Presents var destino: Destino.State?
  }
  enum Action {
    case anadirTocado
    case filaTocada(Item.ID)
    case destino(PresentationAction<Destino.Action>)
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .anadirTocado:
        state.destino = .anadir(FormularioItem.State())
        return .none
      case let .filaTocada(id):
        state.destino = state.items[id: id].map { .detalle(DetalleItem.State(item: $0)) }
        return .none
      case .destino:
        return .none
      }
    }
    .ifLet(\.$destino, action: \.destino)
  }
}

La palabra árbol es literal: si DetalleItem declara a su vez su propio enum de destino, la estructura de tipos que resulta es un árbol cuya altura está escrita en el código. Eso tiene una virtud enorme —el compilador conoce todos los trayectos posibles de la app— y una limitación igual de clara: un flujo que se repita indefinidamente, como ir de un perfil a otro perfil sin final, no es expresable, porque exigiría un tipo infinitamente anidado.

La pila: una colección plana sin fondo

Cuando el trayecto no tiene un final conocido, el modelo correcto es la pila. StackState es una colección ordenada de estados de destino que vive en un solo campo del padre, y forEach corre el reducer de cada pantalla apilada gestionando su ciclo de vida y cancelando sus efectos al desapilar.

@Reducer
struct AppRaiz {
  @Reducer
  enum Camino {
    case perfil(Perfil)
    case publicacion(Publicacion)
  }
  @ObservableState
  struct State: Equatable {
    var inicio = Inicio.State()
    var camino = StackState<Camino.State>()
  }
  enum Action {
    case inicio(Inicio.Action)
    case camino(StackActionOf<Camino>)
  }
  var body: some ReducerOf<Self> {
    Scope(state: \.inicio, action: \.inicio) { Inicio() }
    Reduce { state, action in
      switch action {
      case let .inicio(.delegate(.perfilAbierto(id))),
           let .camino(.element(id: _, action: .perfil(.delegate(.otroPerfil(id))))):
        state.camino.append(.perfil(Perfil.State(id: id)))
        return .none
      default:
        return .none
      }
    }
    .forEach(\.camino, action: \.camino) { Camino() }
  }
}

Fíjate en que los dos orígenes comparten un mismo caso: da igual que el perfil lo abra la pantalla de inicio o que lo abra otro perfil, porque ambos producen un elemento hermano de la misma colección y no un anidamiento nuevo de tipos. Esa es la propiedad decisiva. La pila permite recursión en el recorrido sin recursión en los tipos, y por eso una acción emitida en la pantalla número doce llega a la raíz con dos envoltorios y no con doce: la profundidad del usuario y la profundidad de la composición dejan de ser el mismo número.

El equivalente en SwiftUI y el criterio de elección

Cada modelo tiene su costura exacta en la capa de vista, y no son intercambiables. El árbol se consume con los modificadores que aceptan un elemento opcional; la pila, con un NavigationStack enlazado al camino.

// Árbol: el hueco opcional alimenta un modificador de presentación
.sheet(item: $store.scope(state: \.destino?.anadir, action: \.destino.anadir)) { store in
  FormularioItemView(store: store)
}

// Pila: la colección alimenta el NavigationStack
NavigationStack(path: $store.scope(state: \.camino, action: \.camino)) {
  InicioView(store: store.scope(state: \.inicio, action: \.inicio))
} destination: { store in
  switch store.case {
  case let .perfil(store): PerfilView(store: store)
  case let .publicacion(store): PublicacionView(store: store)
  }
}

El criterio se reduce a dos preguntas encadenadas. Primera: ¿el usuario puede volver a llegar a una pantalla del mismo tipo sin haber salido antes? Si la respuesta es sí, es pila y no hay discusión. Segunda, si la respuesta fue no: ¿la presentación es modal, es decir, interrumpe el trayecto en lugar de continuarlo? Si es modal, es árbol. Lo que queda en medio —un detalle no recursivo que continúa el trayecto— admite ambas, y ahí conviene decidir por coste de composición, que casi siempre favorece a la pila en cuanto hay más de dos escalones.

flowchart TD
A1[Inventario] --> A2[Hueco de destino opcional]
A2 --> A3[Detalle]
A2 --> A4[Formulario]
P0[Raiz] --> P1[StackState de Camino]
P1 --> P2[Perfil]
P1 --> P3[Publicacion]
P1 --> P4[Perfil otra vez]
style A2 fill:#89b4fa,color:#11111b
style P1 fill:#a6e3a1,color:#11111b