Navegación y árbol de estado: la navegación como datos

Pregúntale a una app corriente qué pantalla tiene encima y no sabrá responderte: la respuesta está repartida entre banderas booleanas, delegados de navegación y el estado interno del propio sistema de vistas, y solo se reconstruye ejecutando la secuencia de comandos que llevó hasta ahí. TCA se niega a esa dispersión. Su tesis sobre navegación es la misma que sobre todo lo demás, llevada al extremo: la navegación es estado, y como tal debe ser un dato explícito, modelable, que vive en el State y del que la interfaz es un mero reflejo. Presentar una pantalla no es dar una orden; es asignar un valor. Y como es un valor, se puede guardar, restaurar, enlazar por URL y —lo que más importa en este nivel— afirmar en un test.

@Presents: la presentación opcional como estado

La forma más simple de navegación es opcional: hay una pantalla presentada o no la hay. TCA la modela con un estado hijo opcional marcado con @Presents, y con un caso de acción envuelto en PresentationAction, que unifica dos mensajes: los que vienen de dentro del hijo presentado y el que señala que el hijo se descartó.

@Reducer
struct Lista {
  @ObservableState
  struct State: Equatable {
    var items: IdentifiedArrayOf<Item> = []
    @Presents var detalle: Detalle.State?
  }
  enum Action {
    case itemTocado(Item.ID)
    case detalle(PresentationAction<Detalle.Action>)
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .itemTocado(id):
        state.detalle = Detalle.State(item: state.items[id: id])
        return .none
      case .detalle:
        return .none
      }
    }
    .ifLet(\.$detalle, action: \.detalle) {
      Detalle()
    }
  }
}

Presentar el detalle es una sola línea: state.detalle = Detalle.State(...). Descartarlo es state.detalle = nil. No hay comando de navegación en ningún lado; hay una asignación al estado, y la vista, que observa detalle, presenta la hoja cuando el valor deja de ser nulo. El ifLet que ya conoces corre el reducer del detalle solo mientras exista y cancela sus efectos al descartarse: la presentación y su ciclo de vida son una sola cosa.

El enum de destino: varios destinos, un solo hueco

Cuando una pantalla puede presentar más de un destino —un detalle, una hoja de edición, una alerta— no quieres un opcional por cada uno, porque eso permite el estado imposible de dos presentaciones a la vez. Lo correcto es un único hueco que sea uno de varios: un enum de destino, que con @Reducer se convierte a la vez en la suma de los estados posibles y en la composición de sus reducers.

@Reducer
struct Lista {
  @Reducer
  enum Destino {
    case detalle(Detalle)
    case editar(Editor)
    case alerta(AlertState<Never>)
  }
  @ObservableState
  struct State: Equatable {
    @Presents var destino: Destino.State?
  }
  enum Action {
    case detalleTocado
    case editarTocado
    case destino(PresentationAction<Destino.Action>)
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .detalleTocado:
        state.destino = .detalle(Detalle.State())
        return .none
      case .editarTocado:
        state.destino = .editar(Editor.State())
        return .none
      case .destino:
        return .none
      }
    }
    .ifLet(\.$destino, action: \.destino)
  }
}

Un solo campo destino, de tipo enum: o es .detalle, o es .editar, o es .alerta, o es nulo. Los estados imposibles del bloque de Niveles 9 a 16 reaparecen aquí resueltos por construcción: es aritméticamente imposible tener el detalle y el editor presentados a la vez, porque un enum solo puede estar en un caso. La navegación heredó la lección de las máquinas de estado.

Árbol contra pila: StackState para lo profundo

La presentación opcional modela navegación en árbol: cada pantalla presenta a lo sumo un hijo, y la profundidad la fija el anidamiento de features. Para la navegación en pila —empujar pantallas indefinidamente, como un NavigationStack— TCA ofrece StackState, una colección ordenada de estados de destino, con su acción hermana StackAction.

@Reducer
struct App {
  @Reducer
  enum Ruta {
    case perfil(Perfil)
    case ajustes(Ajustes)
  }
  @ObservableState
  struct State: Equatable {
    var camino = StackState<Ruta.State>()
  }
  enum Action {
    case camino(StackActionOf<Ruta>)
  }
  var body: some ReducerOf<Self> {
    Reduce { state, action in return .none }
    .forEach(\.camino, action: \.camino)
  }
}

Empujar una pantalla es state.camino.append(.perfil(Perfil.State())); retroceder es quitar el último; volver a la raíz es vaciar la colección. Toda la pila de navegación es un array en el estado, y forEach corre el reducer de cada pantalla apilada, cancelando sus efectos cuando se desapila. En la vista, un NavigationStack se enlaza a ese camino mediante $store.scope, de modo que empujar en el estado empuja en pantalla y el botón atrás del sistema quita del estado. Estado y UI quedan atados por una biyección, no por una secuencia de órdenes.

flowchart LR
E[State con navegacion] --> V[Vista renderiza el reflejo]
V -->|intencion del usuario| A[Action]
A --> R[Reduce asigna destino o apila]
R --> E
DL[Deep link o restauracion] -->|asigna estado inicial| E
style E fill:#89b4fa,color:#11111b
style DL fill:#a6e3a1,color:#11111b