El enum Destination: todas las salidas de una feature en un solo tipo

Las dos lecciones anteriores te dieron las dos piezas: un estado hijo opcional que existe o no, y un enum cuyos casos llevan estados hijos mutuamente excluyentes. El patrón que domina la navegación en TCA no es ninguna de las dos por separado, sino su composición exacta: un opcional de un enum. El opcional responde a la pregunta de si esta pantalla ha navegado a alguna parte; el enum responde a la pregunta de a cuál. Juntos forman un único valor que describe por completo la situación de navegación de una feature, y del que se deduce —sin margen para la interpretación— qué hay presentado encima. Ese valor se llama por convención destination, su tipo se llama Destination, y la macro @Reducer sobre un enum convierte el patrón en tres líneas de declaración.

Un enum de destinos anotado con @Reducer

Empieza por el enunciado del problema. Desde la pantalla de un artículo el usuario puede abrir el detalle del autor, editar el artículo o recibir una alerta de confirmación de borrado. Son tres features hijas distintas y tres presentaciones que jamás deben coexistir. La declaración canónica agrupa las tres en un enum y deja que la macro haga el trabajo pesado.

@Reducer
struct Articulo {
  @Reducer
  enum Destination {
    case autor(Autor)
    case edicion(Edicion)
    case confirmarBorrado(AlertState<Alerta>)

    @CasePathable
    enum Alerta { case borrarConfirmado }
  }

  @ObservableState
  struct State: Equatable {
    var texto = ""
    @Presents var destination: Destination.State?
  }

  enum Action {
    case autorTocado
    case editarTocado
    case borrarTocado
    case destination(PresentationAction<Destination.Action>)
  }
}

Observa que los casos del enum no llevan estados, llevan reducers: Autor, Edicion. Esa es la novedad de la macro @Reducer aplicada a un enum. A partir de esa declaración sintetiza dos tipos anidados que sí son de datos y de mensajes: un Destination.State con un caso por cada destino portando el State de su reducer, y un Destination.Action con un caso por cada destino portando su Action. También sintetiza el cuerpo del reducer del enum, que no es otra cosa que un ifCaseLet por caso —exactamente el operador de la lección anterior, escrito por ti tantas veces como destinos tuvieras si la macro no existiera—. El caso de la alerta es el único que no lleva un reducer sino un AlertState, porque una alerta no tiene lógica propia: es datos puros más un enum de acciones que el padre interpreta.

Un solo opcional, un solo caso de acción, un solo ifLet

Con el enum declarado, el reducer padre se compone con el operador de la primera lección, porque Destination.State? no deja de ser un estado hijo opcional.

var body: some ReducerOf<Self> {
  Reduce { state, action in
    switch action {
    case .autorTocado:
      state.destination = .autor(Autor.State(id: state.autorID))
      return .none
    case .editarTocado:
      state.destination = .edicion(Edicion.State(texto: state.texto))
      return .none
    case .borrarTocado:
      state.destination = .confirmarBorrado(
        AlertState {
          TextState("Seguro que quieres borrarlo")
        } actions: {
          ButtonState(role: .destructive, action: .borrarConfirmado) {
            TextState("Borrar")
          }
        }
      )
      return .none
    case .destination(.presented(.confirmarBorrado(.borrarConfirmado))):
      state.texto = ""
      return .none
    case .destination:
      return .none
    }
  }
  .ifLet(\.$destination, action: \.destination)
}

Repara en la última línea: ifLet sin closure. Cuando el estado opcional es un enum anotado con @Reducer, la macro ya proporciona el reducer del destino y no hay nada que pasar. Repara también en la aritmética de la declaración: tres destinos, tres pantallas, un solo campo de estado, un solo caso de acción y un solo operador de composición. Añadir un cuarto destino mañana es añadir un caso al enum y un modificador a la vista; el State del padre, su Action y su body no cambian de forma.

La vista: un modificador por destino sobre el mismo store

En la vista, cada destino se conecta con su modificador de presentación natural, y todos beben del mismo campo de estado a través de un scope que encadena el opcional con el case path del destino.

struct ArticuloView: View {
  @Bindable var store: StoreOf<Articulo>

  var body: some View {
    Form { Text(store.texto) }
      .sheet(
        item: $store.scope(state: \.destination?.edicion, action: \.destination.edicion)
      ) { store in
        EdicionView(store: store)
      }
      .navigationDestination(
        item: $store.scope(state: \.destination?.autor, action: \.destination.autor)
      ) { store in
        AutorView(store: store)
      }
      .alert(
        $store.scope(state: \.destination?.confirmarBorrado, action: \.destination.confirmarBorrado)
      )
  }
}

Los tres modificadores conviven en la misma vista sin conflicto porque los tres consultan el mismo valor y a lo sumo uno de los tres scope produce un store no nulo. Si el destino es .edicion, el scope del autor devuelve nulo y su navigationDestination permanece inerte. La coordinación entre presentaciones, que en el mundo imperativo exige saber qué se presentó antes y esperar a que termine de animarse, aquí no existe como problema porque nunca hay dos candidatos.

flowchart TD
S[campo destination opcional] --> Q{hay valor}
Q -->|nil| P[ninguna pantalla presentada]
Q -->|caso autor| A[navigationDestination con AutorView]
Q -->|caso edicion| E[sheet con EdicionView]
Q -->|caso confirmar borrado| C[alert con AlertState]
style P fill:#89b4fa,color:#11111b
style S fill:#a6e3a1,color:#11111b