La forma canónica de una feature

Hay arquitecturas que presumen de flexibilidad y hay arquitecturas que presumen de uniformidad. TCA pertenece con orgullo a las segundas: cada feature de una app, sea el contador de una demo o la pantalla de pago de un banco, tiene exactamente la misma silueta. Un struct anotado, un estado anidado, una enumeración cerrada de sucesos y un cuerpo declarativo. Esa monotonía deliberada es una ventaja subestimada: cuando abres un archivo desconocido de un proyecto ajeno sabes de antemano dónde está cada cosa, y cuando escribes una feature nueva no tomas decisiones de estructura, solo de contenido. Esta lección fija esa plantilla y explica por qué cada pieza está donde está.

El esqueleto mínimo

Reducido a lo imprescindible, el molde tiene cuatro líneas de estructura y todo lo demás es contenido de tu dominio. Memorízalo: escribirás esta forma más veces que cualquier otra cosa en TCA.

import ComposableArchitecture

@Reducer
struct MiFeature {
  @ObservableState
  struct State: Equatable {
    // todo lo que la pantalla necesita saber
  }

  enum Action {
    // todo lo que puede ocurrirle a la pantalla
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      }
    }
  }
}

Cuatro decisiones están tomadas por ti en ese molde. El tipo es un struct y no una clase, porque un reducer es un valor sin identidad que se copia libremente. State es un struct conforme a Equatable, porque el TestStore compara estados y porque la observación necesita detectar cambios. Action es un enum sin conformidades obligatorias, aunque Equatable te lo pedirán los tests en cuanto los escribas. Y body devuelve some ReducerOf<Self>, azúcar de some Reducer<State, Action>, que es la promesa de devolver algún reducer del mismo dominio sin comprometerte con un tipo concreto.

Por qué el estado vive dentro

Podrías declarar struct MiFeatureState en el ámbito global y referenciarlo. Compilaría, pero perderías tres cosas. La primera es el espacio de nombres: al anidar, MiFeature.State y Otra.State conviven sin colisión y sin prefijos artificiales. La segunda es la inferencia: la macro localiza los tipos por nombre dentro del tipo, como vimos en la lección anterior, y fuera de él no los encuentra. La tercera es cognitiva y es la más importante: la feature se vuelve una unidad legible de arriba abajo, donde el dominio completo cabe en una pantalla del editor.

@Reducer
struct Perfil {
  @ObservableState
  struct State: Equatable {
    var nombre = ""
    var cargando = false
    var error: String?
  }

  enum Action {
    case vistaAparecio
    case perfilRecibido(Result<String, any Error>)
    case reintentarPulsado
  }

  @Dependency(\.clienteAPI) var clienteAPI

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .vistaAparecio, .reintentarPulsado:
        state.cargando = true
        state.error = nil
        return .run { send in
          await send(.perfilRecibido(Result { try await clienteAPI.perfil() }))
        }

      case let .perfilRecibido(.success(nombre)):
        state.nombre = nombre
        state.cargando = false
        return .none

      case let .perfilRecibido(.failure(fallo)):
        state.error = fallo.localizedDescription
        state.cargando = false
        return .none
      }
    }
  }
}

Fíjate en el orden de declaración, que es una convención estable en toda la comunidad: primero State, luego Action, luego las dependencias con @Dependency, y body al final. La razón es de lectura: los dos primeros bloques definen el vocabulario del dominio, las dependencias declaran de qué mundo exterior depende, y body es la única parte con lógica. Quien abre el archivo lee la interfaz antes que la implementación.

La vista al otro lado del Store

La feature es solo la mitad. La otra mitad es una vista que sostiene un StoreOf y lee estado directamente de él, sin capa intermedia, gracias a la observación que instala @ObservableState.

struct PerfilView: View {
  let store: StoreOf<Perfil>

  var body: some View {
    Form {
      if store.cargando {
        ProgressView()
      } else {
        Text(store.nombre)
      }
      if let error = store.error {
        Text(error).foregroundStyle(.red)
        Button("Reintentar") { store.send(.reintentarPulsado) }
      }
    }
    .onAppear { store.send(.vistaAparecio) }
  }
}

Dos gestos y ningún tercero: se lee estado con acceso directo por punto, store.cargando, y se envían acciones con store.send. No hay observadores manuales, no hay WithViewStore como en versiones antiguas, no hay funciones intermedias. La vista es una proyección del estado y un emisor de sucesos, exactamente eso y nada más.

flowchart LR
V[Vista SwiftUI] -->|send accion| S[Store]
S -->|entrega accion| R[Reducer body]
R -->|muta| E[State]
R -->|devuelve| F[Effect]
E -->|observacion| V
F -.nuevas acciones.-> S

Nombrar acciones como hechos

La convención más rentable de TCA no está en la sintaxis sino en el vocabulario. Un caso de Action no debe nombrar una orden sino un hecho ocurrido. La diferencia parece cosmética y es estructural.

La razón profunda es que si la acción nombra la orden, la decisión ya se tomó fuera del reducer y la vista pasó a ser lógica de negocio disfrazada. Si la acción nombra el hecho, todas las decisiones quedan concentradas en un único switch auditable. Cuando una lista de acciones se lee como un registro cronológico de lo que pasó, puedes reproducir una sesión entera leyéndola; cuando se lee como una lista de órdenes, has repartido la lógica.