Dividir un reducer que crece: encontrar el corte y ejecutarlo sin romper nada

Todo reducer que sobrevive lo suficiente engorda. Empieza con seis casos y termina con cuarenta; el State acumula banderas que solo tienen sentido en combinaciones concretas; el compilador tarda cada vez más en verificar el tipo del body; y el test más simple exige construir medio mundo. La tentación es tratarlo como un problema de higiene y trocear el fichero en extensiones, pero eso solo reparte el desorden. Partir bien una feature no es un ejercicio de formato: es descubrir una frontera que ya existía en el acoplamiento entre acciones y estado, y hacerla explícita en el sistema de tipos. Esta lección te da el criterio para encontrarla y el procedimiento para cruzarla sin dejar la app rota ni un solo commit.

Las señales de que hay dos features dentro

El número de líneas es un mal indicador; un reducer de trescientas líneas con un dominio coherente es perfectamente sano, y uno de ochenta puede estar mezclando dos responsabilidades. Las señales que sí importan son estructurales.

La tercera fila es la decisiva y merece formalizarse. Dibuja un grafo bipartito: a un lado los casos de tu Action agrupados por vocabulario, al otro los campos de tu State, y una arista cada vez que un caso lee o escribe un campo. Si el grafo resultante se separa en dos componentes unidos por unas pocas aristas, esas aristas son la interfaz entre dos features y el resto es ruido. Si en cambio el grafo es denso —casi todos los casos tocan casi todos los campos— la feature es una sola por muy larga que sea, y partirla creará dos reducers que se pasan el estado a manotazos.

flowchart LR
A1[acciones de busqueda] --> C1[campo consulta]
A1 --> C2[campo resultados]
A1 --> C3[campo cargando]
A2[acciones de edicion] --> C4[campo borrador]
A2 --> C5[campo validaciones]
A2 -.unica arista cruzada.-> C2
C2 -.el corte pasa por aqui.-> A2

Elegir la cardinalidad antes de mover código

Localizado el corte, la siguiente decisión no es cómo escribir el hijo sino cuántas instancias suyas pueden coexistir, porque esa respuesta elige el operador sin margen de duda: si el hijo existe siempre, Scope; si existe o no, ifLet con @Presents; si existe muchas veces, forEach con IdentifiedArrayOf. Equivocarse aquí es lo que produce las extracciones que hay que deshacer, porque un hijo modelado como permanente cuando en realidad es presentado obliga después a inventar banderas de visibilidad en el padre.

La mecánica en cinco pasos

La clave para no romper nada es que cada paso compile y pase los tests existentes. El truco que lo hace posible es el puente temporal: propiedades calculadas en el padre que reenvían al estado ya anidado, de modo que la vista y las pruebas siguen viendo la forma antigua mientras el interior ya tiene la forma nueva.

// Paso 1: el estado del hijo se anida, pero el padre expone puentes.
@ObservableState
struct State: Equatable {
  var edicion = Edicion.State()
  var articulos: IdentifiedArrayOf<Articulo> = []

  // Puente temporal: se borra en el paso 5.
  var borrador: String {
    get { edicion.borrador }
    set { edicion.borrador = newValue }
  }
}

// Pasos 2 y 3: las acciones se agrupan y la logica se mueve literalmente.
@Reducer
struct Edicion {
  @ObservableState
  struct State: Equatable {
    var borrador = ""
    var validaciones: [String] = []
  }

  enum Action: Equatable {
    case borradorCambiado(String)
    case guardarPulsado
    case delegate(Delegate)

    @CasePathable
    enum Delegate: Equatable { case guardado(Articulo) }
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .borradorCambiado(texto):
        state.borrador = texto
        return .none
      case .guardarPulsado:
        return .send(.delegate(.guardado(Articulo(texto: state.borrador))))
      case .delegate:
        return .none
      }
    }
  }
}

El paso 4 es enchufar el hijo con el operador que eligió la cardinalidad, siempre por encima del Reduce propio del padre, como fijó la segunda lección de este nivel. El paso 5 es retirar los puentes y migrar la vista a store.scope(state:action:), un fichero cada vez; en cuanto el último puente desaparece, el compilador te señala todos los sitios que aún hablaban el lenguaje antiguo, y esa lista de errores es tu plan de trabajo restante.

Devolverle la palabra al padre

Un hijo extraído no puede alcanzar hacia arriba, y esa incapacidad es justo lo que lo hace reutilizable. Cuando necesita que el padre haga algo —cerrar una hoja, insertar el resultado en una lista, navegar— no lo hace: lo anuncia. La convención es un caso delegate en su Action con un enum anidado propio, que el hijo emite con .send y que el padre intercepta en su propio Reduce.

var body: some ReducerOf<Self> {
  Scope(state: \.edicion, action: \.edicion) { Edicion() }

  Reduce { state, action in
    switch action {
    case let .edicion(.delegate(.guardado(articulo))):
      state.articulos.append(articulo)
      return .none
    default:
      return .none
    }
  }
}

Tres precisiones. La primera: el hijo nunca debe reaccionar a sus propios casos delegate; son de salida y su rama devuelve .none. La segunda: como .send produce un Effect, la acción de delegación llega al padre en una pasada posterior, no en la misma; si esperabas verla en el mismo ciclo, el TestStore te lo dirá con un receive obligatorio. La tercera: el vocabulario del delegate debe hablar del dominio del hijo —guardado, cancelado— y jamás del padre —cerrarHoja, irADetalle—, porque en cuanto nombra al padre deja de poder enchufarse en otro sitio.