Arquitectar una app completa: el plano entero, del árbol de features al testing

La pregunta que separa a quien sabe usar TCA de quien sabe arquitecturar con TCA no es cómo se escribe un reducer, sino qué se hace el primer día, cuando no hay ni una línea y hay que decidir en qué se parte una app entera. Esta lección responde a esa pregunta con un procedimiento reproducible de cuatro movimientos, y con una tesis fuerte detrás: solo el primero de los cuatro es una decisión de diseño genuina. El grafo de módulos, la navegación y el plan de pruebas no son elecciones independientes que haya que armonizar después, sino tres lecturas distintas del mismo árbol de estado. Si el árbol está bien, los tres salen casi solos; si está mal, ninguna cantidad de disciplina posterior lo arregla.

Del dominio al árbol de features

El error inaugural es empezar por las pantallas. Las pantallas son una proyección del estado sobre un dispositivo concreto y cambian cuando llega el iPad, el widget o el reloj; el árbol de estado no. Se empieza, por tanto, por el dominio: qué entidades hay, qué relaciones tienen, qué se comparte. Y sobre ese dominio se decide lo único que importa en esta fase, que es la cardinalidad de cada arista entre un padre y sus hijos.

@Reducer
struct AppFeature {
  @ObservableState
  struct State: Equatable {
    var pestana: Pestana = .sesiones
    var listado = Listado.State()            // hijo permanente
    var ajustes = Ajustes.State()            // hijo permanente
    @Presents var destino: Destino.State?    // hijo opcional, uno de varios
    var ruta = StackState<Ruta.State>()      // hijos apilados

    @Shared(.fileStorage(.documentsDirectory.appending(component: "sesiones.json")))
    var sesiones: IdentifiedArrayOf<Sesion> = []   // dominio compartido, no feature
  }
}

La última línea es la que más decisiones ahorra a medio plazo. El dominio compartido —lo que varias features leen y alguna escribe— no se duplica en cada State ni se pasa a mano por el árbol: se declara una vez con @Shared y se sincroniza sin que ningún padre tenga que reenviarlo hacia abajo. Distinguir eso del estado propio de cada feature es la frontera que mantiene el árbol poco profundo, porque casi todo el anidamiento innecesario de una app grande nace de intentar que los datos viajen por las mismas aristas que la navegación.

flowchart TD
ROOT[AppFeature] --> LIS[Listado]
ROOT --> AJU[Ajustes]
ROOT --> DES[Destino como enum]
ROOT --> PIL[Pila de rutas]
DES --> ALE[Alerta]
DES --> EDI[Editor]
PIL --> DET[Detalle]
DET --> RES[Resumen]
SH[Sesiones compartidas] -.-> LIS
SH -.-> DET
SH -.-> RES
style ROOT fill:#89b4fa,color:#11111b
style SH fill:#a6e3a1,color:#11111b
style DES fill:#fab387,color:#11111b

Del árbol de features al grafo de módulos

El segundo movimiento es mecánico si el primero está hecho. Cada nodo del árbol que tenga estado propio, acciones propias y algún efecto se convierte en un objetivo de SPM; cada arista se convierte en una dependencia declarada del padre hacia el hijo, nunca al revés y nunca entre hermanos. Debajo del árbol quedan dos capas que no son features: el dominio, con los tipos de valor, y las interfaces de los clientes. Encima queda la raíz, y encima de la raíz el objetivo de app, que debe caber en una pantalla.

targets: [
  .target(name: "Dominio"),                                        // valores puros
  .target(name: "SesionesCliente", dependencies: ["Dominio", .tca]), // interfaz
  .target(name: "SesionesClienteLive", dependencies: ["SesionesCliente"]),

  .target(name: "ListadoFeature", dependencies: ["SesionesCliente", .tca]),
  .target(name: "DetalleFeature", dependencies: ["SesionesCliente", .tca]),
  .target(name: "AjustesFeature", dependencies: ["Dominio", .tca]),

  .target(
    name: "AppFeature",
    dependencies: ["ListadoFeature", "DetalleFeature", "AjustesFeature", .tca]
  ),
]

Fíjate en que ListadoFeature y DetalleFeature no se conocen, aunque en la app una empuje a la otra. Esa es exactamente la propiedad que hace utilizable el plano: cualquiera de las dos se abre en un preview aislado, se compila en segundos y se testea sin arrastrar la mitad del sistema. La coordinación entre ambas existe, pero vive donde le corresponde, que es en el único objetivo que las conoce a las dos.

La raíz: navegación, arranque y lo vivo

La raíz es el único sitio donde tres cosas ocurren, y conviene enunciarlo como regla porque cada una de las tres es una tentación constante de dispersar. Primero, la traducción de acciones delegate: cuando el detalle anuncia que el usuario borró una sesión, es la raíz la que decide si eso saca una pantalla de la pila, actualiza el listado o abre una alerta. Segundo, el deep linking, que en TCA no es un enrutador sino la construcción directa de un estado inicial. Y tercero, la sustitución de las implementaciones vivas, que es lo único que impide que un objetivo de feature acabe conociendo el mundo real.

@main
struct MiApp: App {
  static let store = Store(initialState: AppFeature.State()) {
    AppFeature()
  }

  var body: some Scene {
    WindowGroup {
      AppView(store: Self.store)
        .onOpenURL { url in Self.store.send(.abrioEnlace(url)) }
    }
  }
}

// En AppFeature: el enlace no navega, construye estado
case let .abrioEnlace(url):
  guard let id = Sesion.ID(url.lastPathComponent) else { return .none }
  state.ruta.append(.detalle(Detalle.State(id: id)))
  return .none

Que abrir un enlace sea añadir un valor a una pila y no ejecutar una transición tiene una consecuencia que se cobra el día del lanzamiento: el deep linking se testea sin simulador, sin URL reales y sin esperar animaciones, porque probar que un enlace lleva a la pantalla correcta es probar que una función construye el estado correcto. La restauración de sesión, la continuidad entre dispositivos y las pruebas de regresión de navegación son el mismo test escrito tres veces.

El plan de testing, que es el árbol otra vez

El cuarto movimiento tampoco es una decisión nueva. Cada nodo del árbol se prueba con un TestStore exhaustivo, y como el nodo contiene toda su lógica, esa prueba unitaria cubre lo que en otras arquitecturas exigiría una prueba de integración. Las aristas se prueban por separado, con exhaustividad reducida, afirmando solo que el padre reacciona como debe al delegate del hijo. Y las hojas del sistema —los clientes vivos— se prueban aparte, contra el mundo real, en pruebas que no pertenecen a la app.

// Arista, no nodo: exhaustividad reducida porque el hijo ya tiene sus tests
let store = TestStore(initialState: AppFeature.State(ruta: .init([.detalle(.init(id: id))]))) {
  AppFeature()
}
store.exhaustivity = .off(showSkippedAssertions: true)

await store.send(\.ruta[id: 0].detalle.delegate.borro)
store.assert { $0.ruta.removeLast() }

La forma resultante no es la pirámide clásica, y conviene decirlo porque desconcierta a quien llega de otras arquitecturas: aquí la base ancha son pruebas de reducer que se ejecutan en milisegundos y afirman comportamiento completo, no pruebas de funciones auxiliares. Lo que se adelgaza es la capa de arriba. Las pruebas de interfaz quedan para lo que solo la interfaz puede fallar —accesibilidad, tamaños dinámicos, un snapshot de una vista compleja— y dejan de ser el sitio donde se descubre que la lógica estaba mal.