Diseñar la jerarquía: hojas, contenedores y profundidad

Los cuatro capítulos anteriores te dieron el mecanismo completo: qué significa componer, cómo funciona Scope por dentro, por dónde viaja una acción y con qué contrato hablan padre e hijo. Nada de eso te dice cuántos niveles debe tener tu app ni qué merece ser una feature. Y esa pregunta importa más que todas las anteriores juntas, porque los errores de mecanismo los caza el compilador en minutos, mientras que un árbol mal repartido no falla nunca: simplemente hace que cada cambio cueste un poco más que el anterior, durante años, sin que nadie sepa señalar el momento en que empezó. Esta lección da el criterio.

Dos especies de feature

Casi todo reducer sano pertenece a una de dos categorías puras, y saber a cuál pertenece el que estás escribiendo resuelve la mayoría de las dudas de diseño sin discusión.

El contenedor canónico se reconoce a simple vista porque su Reduce final no menciona nada que no sea un delegate:

var body: some ReducerOf<Self> {
  Scope(state: \.cabecera, action: \.cabecera) { Cabecera() }
  Reduce { state, action in
    switch action {
    case let .lista(.delegate(.filaSeleccionada(id))):
      state.detalle = Detalle.State(id: id)
      return .none
    case .lista, .cabecera, .detalle:
      return .none
    }
  }
  .forEach(\.lista, action: \.lista) { Fila() }
  .ifLet(\.$detalle, action: \.detalle) { Detalle() }
}

De ahí sale la prueba diagnóstica más útil del nivel: si el Reduce de un contenedor reconoce algo que no sea un caso delegate, está haciendo el trabajo de alguno de sus hijos. O bien esa lógica pertenece al hijo y hay que bajarla, o bien el hijo no debió ser una feature aparte.

El coste real de la profundidad

La profundidad no es cara por elegancia: es cara por aritmética. Cada nivel añade un envoltorio a toda acción que lo atraviese, y ese envoltorio se paga en cuatro monedas distintas.

La primera es sintáctica. Una acción nacida a cuatro niveles llega a la raíz como .pestana(.lista(.fila(id, .delegate(.seleccionada)))), y la profundidad del patrón es una medida literal de la distancia de acoplamiento entre quien emite y quien escucha.

La segunda, y la peor, es el reenvío manual. Si el nieto emite un delegate que le importa al abuelo, hay dos salidas y ninguna es gratis. O el abuelo hace patrón cuatro niveles hacia dentro, y entonces los intermedios dejan de encapsular nada; o cada nivel intermedio declara su propio caso delegate y lo reemite, lo que significa escribir esto una vez por escalón:

// en el nivel intermedio: puro reenvío, N veces
case .fila(.delegate(.seleccionada)):
  return .send(.delegate(.filaSeleccionada))

Ese bloque es intrascendente y multiplicativo: cada evento nuevo cuesta tantas reescrituras como niveles haya. Cuando lo veas aparecer tres veces en el mismo trayecto, no lo estás escribiendo, lo estás pagando.

La tercera es el testing. Las afirmaciones del TestStore heredan exactamente el mismo anidamiento, y un store.receive con cuatro tramos deja de leerse como documentación para leerse como un acertijo. La cuarta es la observabilidad: la salida de _printChanges se vuelve una columna de sangrías donde ya no distingues qué feature hizo qué.

flowchart TD
R[Raiz] --> P[Pestana]
P --> L[Lista]
L --> F[Fila]
F --> E[Etiqueta]
E -. delegate reenviado cuatro veces .-> R
R --> S[StackState de destinos]
S --> D1[Detalle]
S --> D2[Ajustes]
S --> D3[Perfil]
style E fill:#f38ba8,color:#11111b
style S fill:#a6e3a1,color:#11111b

Tres maniobras de aplanado

La primera es preferir la anchura. Un contenedor con cinco hijos directos es más simple que una cadena de cinco niveles, y la asimetría tiene una explicación exacta: la anchura se paga una sola vez, al declarar el State y el Action del contenedor, mientras que la profundidad se paga en cada acción que atraviesa el árbol y en cada delegate que hay que reenviar.

La segunda es adoptar al nieto. Cuando un nivel intermedio no hace nada salvo reenviar —su Reduce es todo reemisión y su State no tiene campos propios—, ese nivel no es una feature, es una tubería con nombre. Bórralo y deja que el abuelo tenga al nieto como hijo directo. El diagrama pierde una caja y la app pierde una clase entera de errores.

La tercera es dejar de confundir navegación con anidamiento. Aquí está el malentendido caro del nivel: mucha gente construye un árbol de reducers que replica el árbol de pantallas, de modo que una pila de cinco pantallas produce cinco niveles de composición. No hace falta, y StackState existe precisamente para evitarlo:

@Reducer
enum Camino {
  case detalle(Detalle)
  case ajustes(Ajustes)
  case perfil(Perfil)
}

@Reducer
struct AppFeature {
  @ObservableState
  struct State: Equatable {
    var raiz = Lista.State()
    var camino = StackState<Camino.State>()
  }
  enum Action {
    case raiz(Lista.Action)
    case camino(StackAction<Camino.State, Camino.Action>)
  }
  var body: some ReducerOf<Self> {
    Scope(state: \.raiz, action: \.raiz) { Lista() }
    Reduce { state, action in
      switch action {
      case let .raiz(.delegate(.filaSeleccionada(id))):
        state.camino.append(.detalle(Detalle.State(id: id)))
        return .none
      default:
        return .none
      }
    }
    .forEach(\.camino, action: \.camino) { Camino() }
  }
}

Lee el State: la pila es un StackState<Camino.State>, es decir, una colección plana. Detalle, Ajustes y Perfil están todos al mismo nivel de composición aunque el usuario los recorra uno detrás de otro, y una acción emitida en la quinta pantalla llega a la raíz con dos envoltorios, no con cinco. La navegación creció; el árbol de reducers, no.